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

Previous Next

Full log

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 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: Fri, 27 May 2022 12:26:56 -0700

[Message part 1 (text/plain, inline)]

On 5/27/22 03:40, Lars Ingebrigtsen wrote:
>> This looks wrong. Shouldn't it leave the DST flag alone? I.e., just this:
>>
>>    (unless (decoded-time-zone time)
>>      (setf (decoded-time-zone-time) default-zone))
>>
>> That is, if we assume that for the DST component -1 means "unknown"
>> and nil means "standard time", it should be OK for
>> decoded-time-set-defaults to leave the DST component alone, for the
>> same reason that it leaves the DOW component alone.

> Yes, I think so.  But you changed this in a391ffa2f03, and you usually
> have a good reason for changes like this, so I thought there must be
> something subtle going on here I didn't quite get.  😀

Thanks for the compliment, not sure it's deserved here....


> The old code doesn't look quite right, either, I think...
> 
> -  ;; When we don't have a time zone and we don't have a DST, then mark
> -  ;; it as unknown.
> -  (when (and (not (decoded-time-zone time))
> -             (not (decoded-time-dst time)))
> -    (setf (decoded-time-dst time) -1))
> -
> -  (when (and (not (decoded-time-zone time))
> -             default-zone)
> -    (setf (decoded-time-zone time) 0))

Yes, that old code was wrong because it incorrectly assumeed that (not 
(decoded-time-dst time)) means the DST flag is unspecified, whereas it 
really means that the DST flag is specifying standard time.

It also looked odd because default-zone was used only as a boolean, even 
though its name suggests that it's the default time zone. This usage 
dates back to commit fa648a59c9818ae284209ac7ae4f3700aebd92c9 which you 
installed in July 2019. The only call using default-zone in Emacs is in 
newsticker--decode-iso8601-date, which passes 0 so that the oddity in 
the implementation makes no difference there.

Part of the confusion here is that nil doesn't mean "no time zone is 
known"; it means "use the Emacs default time zone". In other words, nil 
has the same interpretation problem in time zones that it has in DST 
flags - it doesn't mean "unknown".

To try to lessen the confusion I installed the attached, which fixes the 
reported bug so I'll close the bug report. Please feel free to revert if 
you see a problem with it (I'm just trying to save time here by being bold).

[0001-decoded-time-set-defaults-now-leaves-DST-alone.patch (text/x-patch, attachment)]

Previous Next

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