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.
