GNU bug report logs -
#55635
`make-decoded-time' incorrectly sets DST to nil, it should be -1 (guess)
Previous Next
Full log
View this message in rfc822 format
Consider the following example:
(format-time-string
"%F %T %Z %z"
(encode-time
(make-decoded-time :year 2022 :month 3 :day 31
:hour 23 :minute 30 :second 0
:zone "Europe/Madrid"))
"Europe/Madrid")
"2022-04-01 00:30:00 CEST +0200"
I believe that the result should be
"2022-03-31 23:30:00 CEST +0200"
It can be obtained if :dst -1 is explicitly added to the
`make-decoded-time' arguments.
Since `make-decoded-time' is defined using `cl-defun', I think, it is
better to use -1 ("guess") default value for the :dst argument, not nil
that explicitly says "no daylight saving time".
There is `decoded-time-set-defaults', but it does not help
(format-time-string
"%F %T %Z %z"
(encode-time
(decoded-time-set-defaults
(make-decoded-time :year 2022 :month 3 :day 31
:hour 23 :minute 30)
"Europe/Madrid"))
"Europe/Madrid")
"2022-04-01 01:30:00 CEST +0200"
This case I have no idea how to fix the issue.
An example in the `decoded-time-add' docstring
> (decoded-time-add (decode-time) (make-decoded-time :month 2))
adds even more confusion. If `make-decoded-time' is intended for
intervals, not timestamps than it should not have DST and TZ values at
all. Time interval may be added to timestamp, and time zone and daylight
saving time flag is the property of particular timestamp while the same
interval may be added to various timestamps and the actual result
depends on the base timestamp.
Timestamp and interval are different types and should not be used
interchangeably. nil/t/-1 interpretation difference for DST causes
issues like (bug#54731), so it should be handled with care.
This bug report was last modified 2 years and 338 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.