On 17/04/2022 02:23, Paul Eggert wrote:
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.
I would say that in such cases there is a primary time zone for such
event and secondary time zones of other participants. Time transitions
in the primary time zone (unless it is UTC that is the reference) affect
participants from all other time zones. If some secondary time zone is
changed then it affects only wall time in this particular time zone. So
primary timezone and offsets in all time zones should be stored for user
convenience and to figure out which notification should be sent after
introducing new rules for some time zones.
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.
Before/after time transition around the date may be more meaningful for
people. Local tradition may use other reference than Greenwich.
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. :-)
Numerical abbreviation broke parsers in stable linux distribution, e.g.
a patch for Qt required in addition to tzdata update. I do not remember
details, but removed old-style abbreviations caused some problems as
well. I may be wrong concerning usage of such abbreviation in the
postgres parser and earlier generated text timestamps. On the other hand
an abbreviation for a timezone with evolved offset significantly
contributes to uncertainties and does not help to resolve ambiguity
around time shift.
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 agree that abbreviations are ambiguous when considered globally. When
constrained to particular location (time zone) and moment of time, they
may provide additional bit of information that is more convenient for
users and enough to resolve ambiguity. It is not a general rule,
sometimes uncertainty remains even when abbreviation is known.
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.
Let's assume Europe/Lisbon timezone. `decode-time' for today gives just
+0100. It tells nothing if I need to process some thousands of
timestamps for yesterday and past week. If some function returns "+0100
for given timestamp and the same offset is valid for Europe/Lisbon since
Sun Mar 27 01:00:00 2022 UT = Sun Mar 27 02:00:00 2022 WEST till Sun Oct
30 00:59:59 2022 UT = Sun Oct 30 01:59:59 2022 WEST" then I can process
whole bunch without any worry concerning non-existing or ambiguous time,
extra or lost hour in time intervals. mktime should have all this
information during intermediate calculations but it does not expose it
to callers.
Interface of mktime is suitable for conversion of isolated timestamps.
For bunch of related data there is enough room for optimizing.
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.
They should still have some way to disambiguate whether local time
precedes transition or follows it in various schedules: night trains,
buses, flights. However it might be just "*" and a footnote.
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.
There is no general rule suitable for all cases. In some cases it is
more convenient to store timestamps as seconds since epoch. However
there are cases when it is fragile: dates without time (e.g. birth date
in documents, not for astrology) or future events. Actually input data
should be clearly marked to distinguish from guessed or derived values.
If wall time is what exactly known then UTC offset is secondary data.
When presented to users, UTC offset may sometimes add unnecessary noise
with no real value. I do not dispute that UTC offset is important, I am
just trying to say that sometimes it may be inconvenient in usage.
To build agenda view aside from DST and over transitions and assuming no
travel across time zones, all calculations may be performed without
inspecting of UTC offset.
