From: Paul Eggert <eggert@cs.ucla.edu> To: Max Nikulin <manikulin@gmail.com> Cc: emacs-orgmode@gnu.org, 54764@debbugs.gnu.org Subject: 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.
WARNING: multiple messages have this Message-ID (diff)
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:35 UTC|newest] Thread overview: 106+ 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-09 7:52 ` Paul Eggert 2022-04-09 11:36 ` Max Nikulin 2022-04-10 3:57 ` Max Nikulin 2022-04-13 14:40 ` Max Nikulin 2022-04-13 14:40 ` Max Nikulin 2022-04-13 18:35 ` Paul Eggert [this message] 2022-04-13 18:35 ` Paul Eggert 2022-04-14 13:19 ` Max Nikulin 2022-04-14 22:46 ` Paul Eggert 2022-04-14 22:46 ` Paul Eggert 2022-04-15 2:14 ` Tim Cross 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-21 16:59 ` Max Nikulin 2022-04-16 19:23 ` Paul Eggert 2022-04-19 2:02 ` Paul Eggert 2022-04-19 2:02 ` Paul Eggert 2022-04-19 5:50 ` Eli Zaretskii 2022-04-19 22:22 ` Paul Eggert 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:19 ` Paul Eggert 2022-04-20 18:41 ` Eli Zaretskii 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-20 19:30 ` Eli Zaretskii 2022-04-21 0:11 ` Paul Eggert 2022-04-21 0:11 ` Paul Eggert 2022-04-21 6:44 ` Eli Zaretskii 2022-04-21 6:44 ` Eli Zaretskii 2022-04-21 15:30 ` Max Nikulin 2022-04-21 15:58 ` Eli Zaretskii 2022-04-21 17:23 ` Max Nikulin 2022-04-21 18:46 ` Eli Zaretskii 2022-04-21 23:56 ` Paul Eggert 2022-04-21 23:56 ` Paul Eggert 2022-04-22 5:01 ` Eli Zaretskii 2022-04-22 5:01 ` Eli Zaretskii 2022-04-22 5:23 ` Time resolution in Emacs " Eli Zaretskii 2022-04-22 18:22 ` Paul Eggert 2022-04-22 18:52 ` Corwin Brust 2022-04-22 21:26 ` Paul Eggert 2022-04-23 6:27 ` Time resolution in Emacs Eli Zaretskii 2022-04-24 0:56 ` Paul Eggert 2022-04-24 6:10 ` Eli Zaretskii 2022-04-24 11:47 ` Max Nikulin 2022-04-24 12:23 ` Eli Zaretskii 2022-04-25 15:32 ` Paul Eggert 2022-04-25 16:01 ` Eli Zaretskii 2022-04-22 19:35 ` Time resolution in Emacs argument optional ones Eli Zaretskii 2022-04-22 21:52 ` Paul Eggert 2022-04-23 6:51 ` Time resolution in Emacs Eli Zaretskii 2022-04-25 15:34 ` Paul Eggert 2022-04-25 16:10 ` Eli Zaretskii 2022-04-25 16:38 ` Paul Eggert 2022-04-25 16:57 ` Eli Zaretskii 2022-04-25 16:54 ` Max Nikulin 2022-04-25 17:02 ` Eli Zaretskii 2022-04-25 19:27 ` Paul Eggert 2022-04-29 15:19 ` Max Nikulin 2022-04-29 16:07 ` Eli Zaretskii 2022-04-20 19:23 ` bug#54764: encode-time: make DST and TIMEZONE fields of the list argument optional ones Paul Eggert 2022-04-20 19:14 ` Eli Zaretskii 2022-04-20 19:01 ` Paul Eggert 2022-04-23 14:35 ` Bernhard Voelker 2022-04-23 14:35 ` Bernhard Voelker 2022-04-20 7:23 ` Eli Zaretskii 2022-04-19 5:50 ` Eli Zaretskii 2022-04-20 15:07 ` Max Nikulin 2022-04-20 18:29 ` Paul Eggert 2022-04-20 18:29 ` Paul Eggert 2022-04-25 15:30 ` Max Nikulin 2022-04-25 15:30 ` Max Nikulin 2022-04-25 15:37 ` Paul Eggert 2022-04-25 19:49 ` Paul Eggert 2022-04-25 19:49 ` Paul Eggert 2022-04-30 11:22 ` Max Nikulin 2022-04-30 11:22 ` Max Nikulin 2022-05-01 2:32 ` Paul Eggert 2022-05-01 2:32 ` Paul Eggert 2022-05-01 17:15 ` Max Nikulin 2022-05-01 17:15 ` Max Nikulin 2022-04-25 15:37 ` Paul Eggert 2022-04-20 15:07 ` Max Nikulin 2022-04-15 17:23 ` Max Nikulin 2022-04-14 13:19 ` Max Nikulin 2022-04-13 15:12 ` Max Nikulin 2022-04-13 15:12 ` Max Nikulin 2022-04-16 16:26 ` Max Nikulin 2022-04-16 16:26 ` Max Nikulin 2022-04-17 1:58 ` Paul Eggert 2022-04-17 1:58 ` Paul Eggert 2022-04-20 16:56 ` Max Nikulin 2022-04-20 16:56 ` Max Nikulin 2022-04-20 19:17 ` Paul Eggert 2022-04-20 19:17 ` Paul Eggert [not found] ` <handler.54764.D54764.165091617725815.notifdone@debbugs.gnu.org> 2022-04-25 21:16 ` Glenn Morris 2022-04-26 1:18 ` 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 * 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 \ /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: linkBe 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 external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.