Max Nikulin <maniku...@gmail.com> writes: > On 14/01/2023 18:42, Ihor Radchenko wrote: >> >> <2023-01-14 Sat 18:22@Asia/Singapore> (SGD and similar abbreviations are >> often ambiguous) > > Such format is ambiguous for timezones with DST around backward time > jump. Before/after time transition should be specified in addition, e.g. > by combining identifier and offset or some way to state namely before or > after.
Are you referring to one hour in year when the clock is moved one hour forward? <2023-10-29 Sun 3:00@+DST/Europe/Berlin> -> (+1 minute) <2023-10-29 Sun 2:01@-DST/Europe/Berlin> I, however, do not feel like we need this +/-DST special notation. Chances that one needs a timestamp in this specific hour are slim. At the end, countries deliberately choose the time transition to not interfere with business activity. Instead, we can simply allow https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html formats. All of them are supported by `encode-time' anyway. At least, in theory. I just tried: (time-subtract (encode-time 0 1 3 29 10 2023 nil -1 ":Europe/Berlin") (encode-time 0 59 2 29 10 2023 nil -1 ":Europe/Berlin")) (see https://www.timeanddate.com/time/zone/germany/berlin) and it looks like the expected return value should be 1 hour 2 minutes (3720), but it is not, on my system. I am probably missing something though. >> <2023-01-14 Sat 18:22+0800> >> <2023-01-14 Sat 18:22+08> >> <2023-01-14 Sat 18:22@+0800> >> <2023-01-14 Sat 18:22@+08> > > May become incorrect for future events due to updates of timezone database. Emm. No? +8 is offset from UTC. It will not be affected by anything. Or are you referring to scenarios when user actually wants to specify the timestamp for specific country/city? Then the TZ variant should be used instead. What I am essentially proposing in these examples is allowing: 1. TZ format as described in https://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html 2. ISO 8601 format https://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators Of course, individual variants of time zone specs may be ambiguous depending on the purpose. Users are to choose what they prefer >> <2023-01-14 Sat 18:22@+08 +1w -5d> > > May be not suitable for time zones with DST since offset changes due to > time transitions. > > I am afraid, sometimes rather long (maybe even redundant) specification > is required, so overlays becomes must have (as for links) to keep > readability. Not necessarily. Most of the timestamps can do just fine specifying either explicit offset or a time zone name: <2023-01-14 Sat 18:22@Asia/Singapore> <2023-01-14 Sat 18:22+08> More exotic scenarios will not be common. And, if the users wish, we do have `org-time-stamp-custom-formats'. -- Ihor Radchenko // yantar92, Org mode contributor, 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>
