GNU bug report logs - #55635
`make-decoded-time' incorrectly sets DST to nil, it should be -1 (guess)

Previous Next

Full log

Message #31 received at 55635-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, 55635-done <at> debbugs.gnu.org,
 Maxim Nikulin <m.a.nikulin <at> gmail.com>
Subject: Re: bug#55635: `make-decoded-time' incorrectly sets DST to nil, it
 should be -1 (guess)
Date: Sat, 28 May 2022 10:25:51 -0700

On 5/28/22 09:53, Eli Zaretskii wrote:
> this situation already exists with time units anyway.  You can add
> an hour to some other time, but there's also a valid time stamp that
> expresses 1 hour past the epoch UTC, and their values are exactly
> identical.

Quite true for encoded times that count seconds. However, Max also has a 
point that decoded timestamps like (19 17 10 28 5 2022 6 t -25200) are 
problematic as relative times. Although their first six elements can be 
treated as either relative or absolute, their last three elements don't 
make much sense in relative times.

The recent change in the master branch that lets encode-time take 
six-element lists suggests that perhaps a better way to represent a 
relative decoded time would be as a 6-element list.

With that in mind, here are three suggestions.

1. decoded-time-dst should return -1, instead of nil, when given a 
6-element list, since nil means standard time and -1 means DST is unknown.

2. make-decoded-time should generate a six-element list unless given a 
DST or ZONE arg.

3. Document the above nicely. (This is the hardest part....)

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.