From: Paul Eggert <eggert@cs.ucla.edu>
To: Max Nikulin <manikulin@gmail.com>
Cc: emacs-orgmode@gnu.org, 54764@debbugs.gnu.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: <507cc0a2-d2d9-4283-7cc2-0da3c6510ac8@cs.ucla.edu> (raw)
In-Reply-To: <5cd820d4-ae67-43d4-9e63-c284d51ff1e4@gmail.com>
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 \
--in-reply-to=507cc0a2-d2d9-4283-7cc2-0da3c6510ac8@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=54764@debbugs.gnu.org \
--cc=emacs-orgmode@gnu.org \
--cc=manikulin@gmail.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).