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: Wed, 13 Apr 2022 11:35:55 -0700 [thread overview]
Message-ID: <2dd15844-01b3-0144-740c-185ec8488a81@cs.ucla.edu> (raw)
In-Reply-To: <c6525aa8-1496-8ebe-cf2a-24f65cc44672@gmail.com>
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.
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 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.
> `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.
> 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.
next prev parent reply other threads:[~2022-04-13 18:38 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 [this message]
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
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=2dd15844-01b3-0144-740c-185ec8488a81@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).