Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones

[Paul Eggert <eggert@cs.ucla.edu>]

On 4/15/22 10:23, Max Nikulin wrote:

> if you are storing future events bound to wall time then namely 
> time zone identifier should have precedence.

Although that would make sense for some applications it's not a good 
idea in general. For example, if you're scheduling a Zoom meeting you 
should save both, because other meeting participants may interpret 
strings like "Pacific/Apia" differently.


> Just identifier may be ambiguous around DST transition. So timezone 
> abbreviations are ambiguous per se but when identifiers are known they 
> may be still necessary to resolve uncertainties for backward time 
> shifts. At certain moment the Olson DB started to use "+04" 
> abbreviations instead of letters for transitions unrelated to daylight 
> saving time.

Yes, timezone names like "Europe/Lisbon" are ambiguous during fallback 
transitions, or if the meaning of "Europe/Lisbon" changes. This is why 
one should also save UT offsets when generating localtime timestamps.

Around five years ago I changed TZDB to numeric use time zone 
abbreviations like "+04" instead of my inventions like "GET", because I 
wanted TZDB to follow existing practice, not invent it. A nice side 
effect is that numeric abbreviations are unambiguous. (Besides, even _I_ 
couldn't remember what "GET" meant. :-)


> And WET/WEST gets another bit of info in addition to numerical offset.

That info is meant only for users; I wouldn't rely on it for 
calculations because those abbreviations are ambiguous. It could well 
be, for example that the meaning of "PST" in the United States will 
change in the near future.


> I do not remember if it is possible at all to obtain using libc the 
> period of constant time offset, when time shift value is valid. 
> Sometimes it is necessary to recalculate offset.

Sorry, I don't understand this point. One can easily recalculate the UT 
offset in Emacs Lisp by generating the desired timestamp and calling 
decode-time on it. You surely are talking about something else, but I 
don't know what it is.


> You wrote that "2021-01-31 23:30:00 +0300" is parsed correctly. My 
> opinion is that when time zone is known to be Africa/Juba (system-wide 
> setting, environment variable, or an argument of the parsing function) 
> then "2021-01-31 23:30:00 CAT" and "2021-01-31 23:30:00 EAT" should be 
> parsed correctly (and localized date-time formats should be parsed as 
> well).

That's not possible in general, since the two abbreviations can be the 
same. Traditionally in Australia, for example, "CST" meant both "Central 
Standard Time" and "Central Summer Time", and there are probably still 
apps that use the equivalent of TZ="CST-9:30CST,M10.1.0,M4.1.0/3" which 
does precisely that.

It's hardly ever a good idea to rely on time zone abbreviations as 
they're too often ambiguous. It's much better to use UT offsets. When 
generating a localtime timestamp, one should always output its UT offset 
(in addition to any other advisory info you might want to output). And 
if you do that, many of the abovementioned problems are easily solved.