"Dmytro Kostiuchenko" <[email protected]> writes: > ** Mixed offset + zone ** > > I am less convinced about the mixed offset+zone forms. > > For planning, I would expect the IANA zone to be the source of truth, > because it is what lets Org preserve intent across DST transitions and > future timezone-rule changes. For recording past events, the numeric > offset is enough to preserve the observed instant. If the original > zone name is also useful as human-facing context, could we keep it in > the existing trailing timestamp syntax instead of making it part of > TZSPEC? > > For example: > > <2026-07-19 Sun 12:00 @+0200 Europe/Kyiv> > > My concern is that @+02,Europe/Kyiv and the ! variants would > significantly complicate the implementation. They require parsing and > storing two timezone-like values, validating them against each other, > deciding which one wins on mismatch, preserving that decision through > editing, and making sure all timestamp operations follow the same > conflict policy. I do not yet see a use case that justifies that > complexity.
Yes, it will somewhat complicate the implementation. The logic behind @+02,Europe/Kyiv is tied to planning the meetings that are in other timezone than you. Such planning often comes with mistakes, when DST or even offset is not correctly identified leading to missed meeting times. In such scenario, @+02,Europe/Kyiv basically means "I *think* Europe/Kyiv is at UTC+2 offset at the timestamp time". Then, Org can identify the mismatch, helping to spot the problem easily. That said, I agree that it does not have to be something that must be implemented. We may start from easier format and add offset+timezone name in the future. >> > #+begin_src elisp >> > (:instant TIME >> > :zone ZONE >> > :effective-zone EFFECTIVE-ZONE >> > :granularity GRANULARITY) >> > #+end_src >> >> Do we really need it? Can't we derive the time from >> :year-start/:month-start/:day-start/:hour-start/:minute-start? > > I feel that all arithmetic, comparison, agenda sorting, and export > should rely on a normalized form. This is the surest way to avoid > mistakes around timezone conversion and DST transitions. You can simply use `org-timestamp-to-time'. Storing exact time forces specifying hours, minutes, and seconds to be 0, which looses the information about whether timestamp has/does not have them. > We could parse to the existing timestamp plist and normalize every time > an operation needs it. However, to me it is easier to reason about the > code if we parse to the normalized form internally and treat the > existing timestamp plist as one possible representation of that > normalized data. The public API can still expose the existing plist > shape, but the operations that need time semantics should go through > the normalized representation. IMHO, org-timestamp-to-time should be enough. Introducing information redundancy into the AST object may lead to more confusion, and I do not feel like breaking change to completely change the properties is justified (see the above). -- 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>
