|
From: | Paul Eggert |
Subject: | bug#55635: `make-decoded-time' incorrectly sets DST to nil, it should be -1 (guess) |
Date: | Thu, 26 May 2022 19:11:53 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 |
On 5/26/22 05:13, Lars Ingebrigtsen wrote:
perhaps -1 is less "filled out" than nil in this case.
Indeed it is, and make-decoded-time's DST flag should default to -1.It's unfortunate that nil means "standard time" in these contexts. In hindsight some other symbol should have been used to mean "standard time". Could be too late to change this though.
It's this code, I guess: ;; When we don't have a time zone, default to DEFAULT-ZONE without ;; DST if DEFAULT-ZONE if given, and to unknown DST otherwise. (unless (decoded-time-zone time) (if default-zone (progn (setf (decoded-time-zone time) default-zone) (setf (decoded-time-dst time) nil)) (setf (decoded-time-dst time) -1)))
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.
[Prev in Thread] | Current Thread | [Next in Thread] |