From: Max Nikulin <manikulin@gmail.com>
To: Paul Eggert <eggert@cs.ucla.edu>
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: Thu, 14 Apr 2022 20:19:04 +0700 [thread overview]
Message-ID: <4a23f3a4-fe8f-d396-49d8-10034803be63@gmail.com> (raw)
In-Reply-To: <2dd15844-01b3-0144-740c-185ec8488a81@cs.ucla.edu>
On 14/04/2022 01:35, Paul Eggert wrote:
> On 4/13/22 07:40, Max Nikulin wrote:
>>
>> I do not see a way to get 23:30 EAT +0300.
>
> Are you asking for a function F where you say, "I want to give F a
> possibly-ambiguous decoded local time D, and for F to return all
> timestamps that map to D"? If so, encode-time doesn't do that, because
> the underlying C API (namely, mktime) doesn't do that. All mktime and
> encode-time do is give you *one* timestamp that maps to D; it won't give
> you any other timestamps.
I am just trying to convince you that new API still can not handle
ambiguities in response to:
>>> Unfortunately it makes the function more convenient to
>>> use incorrectly. This was part of the motivation for the API change.
>>> The obsolescent calling convention has no way to deal with ambiguous
>>> timestamps like 2022-11-06 01:30 when TZ="America/Los_Angeles".
Completely ignoring DST in old API is a bug. Possibility to omit DST and
ZONE is a feature for convenience and it is not related to
correctly/incorrectly. It has no common with allowing 6-values
SECONONDS...YEAR list.
I am aware of mktime and my opinion is that libc in such cases (dealing
with formats for humans) is hardly usable for applications more complex
than "hello world".
I do not want all ambiguous time values. I want to provide hints how
they should be resolved and get in response an additional value that
says in which way it is actually resolved.
> If you're worried about possibly-ambiguous decoded local times, you
> could probe (say) one day before and one day after encode-time's result
> to see if the UTC offset changes, and let that guide you to find other
> possible timestamps that map to the decoded time. Although this is just
> a heuristic it should be good enough.
I would prefer to avoid dances with +/-1 day timestamps. I would not be
surprised when one day they will give wrong result. During computations
it is available to which interval of time current time offset is valid.
Such value may be included in result of conversion. So date-time +
"America/Los_Angeles" input should not be reduced to timezone offset in
the output. Zone internal object or identifier is important for
calculation of other date-time values based on the origin value.
> I doubt whether you need to do that, though. Code that is not careful
> about local time offsets doesn't care how ambiguous decoded times are
> resolved. And code that does care should record UTC offsets anyway, and
> you can use those offsets to disambiguate the decoded times. Something
> like this, say:
>
> (defun encode-and-format-time (time tz)
> (let ((etime (encode-time (parse-time-string time))))
> (format-time-string "%F %T %Z %z" etime tz)))
>
> With this definition, (encode-and-format-time "2021-01-31 23:30:00
> +0300" "Africa/Juba") yields "2021-01-31 23:30:00 EAT +0300", which is
> the timestamp you want.
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". I hope, they may work without
explicitly providing time zone offset to the input that anyway requires
additional calculations.
±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.
If agenda interval start falls on skipped time span in local time then
the value immediately after transition should be used (and maybe user
should be warned by additional entry). For agenda end interval vice
versa local time immediately before transition is more suitable.
`parse-time-string' has another set of problems. It is impossible to
specify particular format like for strptime(3). Actually parsing a
string to numerical values and resolving ambiguities in numerical values
are different tasks and it may be useful to have separate functions for
them. I am unsure however concerning implementing constraints to parse
free-form dates.
>> `encode-time' should only accept time zone as time offset and should
>> not allow default or named value that may be ambiguous.
>
> If we're talking about Org's encode-time substitute, you can of course
> do what you like. But Emacs encode-time has supported ambiguous
> timestamps for some time and I expect it's used by apps that don't care
> how ambiguous decoded times are resolved, which means we shouldn't
> remove that support without having a very good reason.
There is no reason to impose such restrictions for helpers in Org since
Org relies on resolving ambiguities with minimal efforts.
`encode-time' supports just one kind of ambiguities. Even though it is
the most common one, it is rather (partially false) impression than real
support.
The truth is that most of developers are not aware of real complexity of
dealing with time. Documentation rarely describes limitations and corner
cases that should be handled. Even when correct time handling gets more
priority it appears that available libraries are full of bugs and
require ugly workarounds.
>> should be possible to provide hints to `encode-time' to get
>> deterministic behavior in the case of time transitions
>
> Yes, that feature is already there. The hint is the UTC offset, as
> illustrated above.
No, 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. In some cases offset should be replaced by time
zone identifier to avoid incorrect result in further calculations.
So I still do not see any point in mandatory DST and ZONE fields in new
interface of `encode-time'. I do not see an alternative to convert
SECONDS...YEAR values to timestamp assuming local time zone as well.
Anyway DST is not available in advance and sometimes DST value is not
coupled with step in local time, so its ability to resolve ambiguities
is limited.
next prev parent reply other threads:[~2022-04-14 13:19 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-07 12:37 bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones 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 [this message]
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
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=4a23f3a4-fe8f-d396-49d8-10034803be63@gmail.com \
--to=manikulin@gmail.com \
--cc=54764@debbugs.gnu.org \
--cc=eggert@cs.ucla.edu \
--cc=emacs-orgmode@gnu.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public 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).