From: Paul Eggert <email@example.com> To: Max Nikulin <firstname.lastname@example.org> Cc: email@example.com, firstname.lastname@example.org 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 [thread overview] Message-ID: <email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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.
next prev parent reply other threads:[~2022-04-16 19:23 UTC|newest] Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-07 12:37 Max Nikulin 2022-04-09 7:52 ` Paul Eggert 2022-04-10 3:57 ` Max Nikulin 2022-04-13 14:40 ` Max Nikulin 2022-04-13 18:35 ` Paul Eggert 2022-04-14 13:19 ` Max Nikulin 2022-04-14 22:46 ` Paul Eggert 2022-04-15 2:14 ` Tim Cross 2022-04-15 17:23 ` Max Nikulin 2022-04-16 19:23 ` Paul Eggert [this message] 2022-04-21 16:59 ` Max Nikulin 2022-04-19 2:02 ` Paul Eggert 2022-04-19 5:50 ` Eli Zaretskii 2022-04-19 22:22 ` Paul Eggert 2022-04-20 7:23 ` Eli Zaretskii 2022-04-20 18:19 ` Paul Eggert 2022-04-20 18:41 ` Eli Zaretskii 2022-04-20 19:01 ` Paul Eggert 2022-04-20 19:14 ` Eli Zaretskii 2022-04-20 19:23 ` Paul Eggert 2022-04-20 19:30 ` Eli Zaretskii 2022-04-21 0:11 ` Paul Eggert 2022-04-21 6:44 ` Eli Zaretskii 2022-04-21 23:56 ` Paul Eggert 2022-04-22 5:01 ` Eli Zaretskii 2022-04-23 14:35 ` Bernhard Voelker 2022-04-20 15:07 ` Max Nikulin 2022-04-20 18:29 ` Paul Eggert 2022-04-25 15:30 ` Max Nikulin 2022-04-25 15:37 ` Paul Eggert 2022-04-25 19:49 ` Paul Eggert 2022-04-30 11:22 ` Max Nikulin 2022-05-01 2:32 ` Paul Eggert 2022-05-01 17:15 ` Max Nikulin 2022-04-13 15:12 ` Max Nikulin 2022-04-16 16:26 ` Max Nikulin 2022-04-17 1:58 ` Paul Eggert 2022-04-20 16:56 ` Max Nikulin 2022-04-20 19:17 ` Paul Eggert
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://www.orgmode.org/ * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Code repositories for project(s) associated with this inbox: https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).