On 15/04/2022 05:46, Paul Eggert wrote:
On 4/14/22 06:19, Max Nikulin wrote:
date-time + "America/Los_Angeles" input should not be reduced to
timezone offset in the output.
It depends on the application. For some applications (e.g., generating
"Date:" lines in email), it is entirely correct to output a timestamp
like "14 Apr 2022 15:16:04 -0700", thus losing the fact that the
timestamp was generated with TZ="America/Los_Angeles".
However if you are storing future events bound to wall time then namely
time zone identifier should have precedence. A new rule may be issued
between scheduling event and the time it will happen. It is terrible
feeling when it is necessary to guess if a web site stores TZ offset or
its identifier and in the latter case whether its administrators updated
tzinfo. It is better to store location of event since a time zone may be
split and time transition may apply only to a part of the original zone.
Actually I meant another case. Some representation is got for a time
moment and it is necessary to get local time for another time moment.
Time zone identifier or an object with internal representation allow to
get correct offset for second moment of time. It should be possible to
specify whether a function call is isolated conversion or further
calculations will follow.
Zone internal object or identifier is important for calculation of
other date-time values based on the origin value.
Again, that depends on the application. It's typically wrong to store an
old timestamp in a form like "1950-07-01 00:00 Europe/Lisbon", because
there is no standard for what "Europe/Lisbon" means. If you update your
copy of TZDB, or interpret such a timestamp on another computer, that
can change the interpretation of such a timestamp. In this particular
case, a change in TZDB release 2021b altered the interpretation of this
old timestamp because we discovered that DST was observed in 1950 in
Portugal.
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.
If you want to keep the TZDB identifier for advice about how to
interpret dates relative to a timestamp, that's fine. But you should
keep the UT offset in addition to the TZDB identifier, if you want your
app to be fully accurate and useful. For example, you should store
"1950-07-01 00:00:00 +0000 Europe/Lisbon" for a timestamp generated by
TZDB release 2021a, so that when you interpret the timestamp in release
2021b you'll have an idea of what you're dealing with.
And WET/WEST gets another bit of info in addition to numerical offset.
I hope, they may work without explicitly providing time zone offset to
the input that anyway requires additional calculations.
It doesn't require additional calculations on the Emacs Lisp user's
part. All you need to do is save the UT offset, and use it later.
There's so little overhead to this that it's not worth worrying about.
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.
±n hours may mean ±n*3600 seconds or time with same minutes and
seconds values but hours value is changed by n even if a 30 min DST
transition happens in between.
Sorry, I don't understand what this sentence is intended to mean.
Let's consider Australia/Lord_Howe with 30min backward DST shift at
2022-04-03 02:00. 8 hours from 2022-04-02 22:00 may mean 2022-04-03
06:00 for duration of the night shift (8:30 instead of usual 8:00). Some
technological process requiring precisely 8 hours finishes at 05:30 in
such case. So it is not equivalent to add 8 hours or 480 minutes. In the
former case it is more convenient to increment particular field and
adjust the result if it coincides with ambiguity/impossible range. In
the latter case it is better to increment timestamp as seconds since the
epoch and back to time fields (leaving aside leap seconds).
`parse-time-string' has another set of problems.
Sure, but that was just an example. You can write your own date parser.
The point is that when you save a localtime timestamp, you should save
its UT offset too, in whatever notation is appropriate.
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). For transitions without DST change there is no conventional text
representation.
UTC offset is another feature and implementing the hints I have tried
to describe may require implementing from scratch full stack of time
handling functions.
I doubt whether that's a good idea. I've written that sort of code, and
it's a lot more work than one might think and it's notoriously difficult
to do it correctly. You have better things to do.
Elisp implementation of date-time library is not in my TODO list. I just
know that there are enough implementations already (and some of them may
be/was buggy):
-
https://github.com/moment/moment-timezone/blob/develop/moment-timezone.js and
currently browsers should have their own implementations
- https://github.com/php/php-src/blob/master/ext/date/lib/parse_tz.c
-
https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/time/qtimezoneprivate_tz.cpp
- https://github.com/HowardHinnant/date/blob/master/src/tz.cpp
and I have heard of more libraries.
There are a lot of corner cases, so "universal" rules will unavoidably
fail. Flexible API may alleviate some cases.
P.S. Once I noticed the following comment on stackoverflow:
Cubbi Jun 12, 2012 at 22:26
> std::broken_promise is the best named identifier in the
> standard library. And there is no std::atomic_future.
https://stackoverflow.com/questions/11004273/what-is-stdpromise
mktime(3) man page uses "broken-down time" term for struct tm. It
explains why it is not unusual when code dealing with time is broken.
