"Dmytro Kostiuchenko" <[email protected]> writes: > I know this has been discussed before, probably more than once. In > particular, there was a January/February 2023 thread starting from > "[FEATURE REQUEST] Timezone support in org-mode datestamps and > org-agenda", followed by discussion of proposed timestamp syntax: > > https://lists.gnu.org/archive/html/emacs-orgmode/2023-01/msg00313.html > https://lists.gnu.org/archive/html/emacs-orgmode/2023-01/msg01025.html > > I would nevertheless like to raise the timezone issue again, this time > with a proof of concept implementation.
Working on timezone support is certainly welcome. Thanks! > A disclaimer about my perspective: I have spent a lot of time building > task schedulers and systems that need to treat time zones, DST > transitions, floating times, and absolute instants carefully. > > However, I am a very lightweight Emacs and Org user (and better > timezone handling is one of the things that could change that ;). > Thus, I have no prior experience with Emacs Lips, I don't know the > conventions and internals of either project. I relied heavily on LLMs > to implement this change. Please note that we currently do not accept LLM contributions. It is a temporary GNU policy that will be re-considered after they assess (with the help of lawyers) whether LLM risks GPL licensing. We can, however, discuss general implementation plan that can later be used to prepare a independent patch. > * The change overview > > The change adds explicit IANA timezone support to Org timestamps while > preserving the current timestamp API and the default interpretation of > existing Org files. > > The change focuses on supporting the following expressions: > > #+begin_src org > <2026-07-19 Sun 12:00 Europe/Kyiv> > <2026-07-19 Sun 12:00-13:00 Europe/Kyiv> > <2026-07-19 Sun 12:00 Europe/Kyiv>--<2026-07-19 Sun 14:00 Europe/Warsaw> > <2026-07-19 Sun 12:00 Europe/Kyiv +1w> > #+end_src Is there any particular reason you did not use the format we settled upon in the threads you linked to? As a reminder, the format is: <YYYY-MM-DD [DAY] [HH:MM[-HH:MM]] @TZSPEC> =TZSPEC= is one of: @+02 ;; UTC offset only @+0230 ;; offset with minutes @Z ;; Zulu (UTC) @Europe/Kyiv ;; IANA zone name @+02,Europe/Kyiv ;; offset + zone, warn on mismatch (default) @!+02,Europe/Kyiv ;; -- use offset, ignore zone @+02,!Europe/Kyiv ;; -- use zone, ignore offset Examples: <2026-07-19 Sun 12:00 @Europe/Kyiv> <2026-07-19 Sun 12:00-13:00 @Asia/Singapore> <2026-07-19 Sun 12:00 @+02,Europe/Kyiv> <2026-07-19 Sun 12:00 @Europe/Kyiv +1w> <2026-07-19 Sun 12:00 @Europe/Kyiv>--<2026-07-19 Sun 14:00 @Europe/Warsaw> > Today, the Org parser accepts these expressions because timestamp > regexps are loose about trailing timestamp content. However, the > detailed timestamp object does not keep the timezone as structured data > and conversion to an Emacs time value uses the ambient local timezone. > > The cornerstone of my change is a new internal normalized > representation for timestamp: > > #+begin_src elisp > (:instant TIME > :zone ZONE > :effective-zone EFFECTIVE-ZONE > :granularity GRANULARITY) > #+end_src > > where: > - =:instant= is the resolved Emacs time value, > - =:granularity= captures whether the timestamp is date-only or > contains time. Do we really need it? Can't we derive the time from :year-start/:month-start/:day-start/:hour-start/:minute-start? Also, what about ranges? > - =:effective-zone= is the zone used to encode/decode the instant. It > matches =:zone= when =:zone= is specified; otherwise it is derived > from the environment... Do we need to store it? We can derive the timezone from the environment any time. Ideally, the parser should only store what is in Org document. > - =:zone= is the explicit IANA zone written by the user, or nil, This is ok. -- Ihor Radchenko // yantar92, Org mode maintainer, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
