emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Eggert
Subject: Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones
Date: Sat, 16 Apr 2022 12:23:25 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]