[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: |
Thu, 14 Apr 2022 15:46:58 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 |
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".
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.
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.
I want hints like "in the case of ambiguity resolve to transition time immediately
before/immediately after transition" or "provide suitable time prior to/after to
transition".
Although that might be nice it's not what mktime gives us, and I doubt
whether it's a good idea to try to implement it from scratch in Emacs.
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.
±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.
`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.
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.
So I still do not see any point in mandatory DST and ZONE fields in new
interface of `encode-time'.
I think we're in agreement here. As I mentioned earlier, I plan to
modify Emacs encode-time so that you can pass it a 6-arg list as well as
an 9-arg list. Once this change is in, the DST and ZONE fields will not
be mandatory.
- bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Max Nikulin, 2022/04/07
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Paul Eggert, 2022/04/09
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Max Nikulin, 2022/04/09
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Max Nikulin, 2022/04/13
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Paul Eggert, 2022/04/13
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Max Nikulin, 2022/04/14
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones,
Paul Eggert <=
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Tim Cross, 2022/04/14
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Max Nikulin, 2022/04/15
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Paul Eggert, 2022/04/16
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Max Nikulin, 2022/04/21
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Paul Eggert, 2022/04/18
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Eli Zaretskii, 2022/04/19
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Paul Eggert, 2022/04/19
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Eli Zaretskii, 2022/04/20
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Paul Eggert, 2022/04/20
- Re: bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones, Eli Zaretskii, 2022/04/20