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

Previous Next

Package: emacs;

Reported by: Maxim Nikulin <m.a.nikulin <at> gmail.com>

Date: Wed, 25 May 2022 14:48:02 UTC

Severity: normal

Done: Paul Eggert <eggert <at> cs.ucla.edu>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Maxim Nikulin <m.a.nikulin <at> gmail.com>
To: 55635 <at> debbugs.gnu.org
Subject: bug#55635: `make-decoded-time' incorrectly sets DST to nil, it should be -1 (guess)
Date: Wed, 25 May 2022 21:46:50 +0700
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.