Hi,
I have only partly been able to follow the discussion, but this seems like a very thoughtful proposal. I'm just not super happy with the ISO format running clock time and offset together, which I thinks makes clock times less readable when you're just quickly glancing through notes. > Examples: > 2022-11-12 12:00+02 # 12:00 UTC+2 > 2022-11-12 14:00+0230 # 14:00 UTC+2:30 > 2022-11-12 14:00-0230 # 14:00 UTC-2:30 > 2022-11-12 14:00Z # 14:00 UTC The '12:00+02' offset is not the 'dd:dd' shape I expect a clocktime in. Also, since I don't think in UTC offsets, my brain goes '12:00 plus 2 hours' before 'the 12:00 that's 2 hours ahead of Greenwich'. The extra cognitive load is admittedly small, and I'd probably probably get used to it quickly if it were only the '+dd'. But I might still get tripped up by an offset like '14:00-0230', which is unambiguous to a computer, but synonymous with '14:00-02:30' to my brain. >From this perspective I'd be happier with the less concise, but super explicit 2022-11-12 14:00 UTC+2 2022-11-12 14:00 UTC-2:30 but I realize there are many considerations to balance here. Yours, Christian > The offset is a subset of what is defined by ISO8601. > > Note that unlike ISO8601, ":" is not allowed in the offset specifier. > This is to disambiguate with the time intervals in Org timestamps: > [2022-11-12 8:00-9:00] in Org is a time range from 8am to 9am. > > For time ranges, we will only allow a single offset and time zone > specifier for both start and end times: > [2022-11-12 8:00-9:00+08] > If different time zones are necessary to specify the start/end times, > users can still use full timestamp range syntax > [2022-11-12 8:00+03]--[2022-11-12 22:00+08] > > The format is also forward-compatible with extending Org timestamps > for second/sub-second precision: 2022-11-12 14:00:05.0012+0230 will > remain valid if we decide to adopt such format. > > 2. Timestamp with time zone specifier > > YYYY-MM-DD [optional day name] HH:MM[^ ]* @[!]?<[^ \]>]> > > For now, time zone name will only be processed when it follows TZ > POSIX format. If necessary, the proposed syntax will still allow > extensions to TZ POSIX. > > Examples: > 2022-11-12 12:00 @Asia/Singapore # tzdb syntax > 2022-11-12 10:00 @Europe/Berlin > 2022-11-12 10:00 @!Europe/Berlin # "!" does nothing here, see below > 2022-11-12 10:00 @EST+5 # TZ syntax > 2022-11-12 10:00 @EST+5EDT,M3.2.0/2,M11.1.0/2 # manual time zone spec > allowed in TZ > > The "@" symbol is selected to disambiguate time zone specifier from > other auxiliary information in the timestamp. Like calendar name, > which might be added in future. Note that we cannot use [...] from > the standard draft. I selected "@" because it is read as "at" - > location specifier. > > The "!" symbol is adapted from > https://datatracker.ietf.org/doc/draft-ietf-sedate-datetime-extended/ > > I use space before "@" to improve readability. We deviate from the > standard here so may as well. In contrast, no space before [+-]offset > is closer to the standard yet not cluttering the timestamp too much > (IMHO). > > 3. (1) and (2) can be combined > > 2022-11-12 12:00+08 @Asia/Singapore > > Org will unconditionally use +08 offset and ignore the time zone > name. We prefer absolute offset because it is non-ambiguous wrt > out-of-date tzdb on the computer. One may also not update the TZ > variable upon travelling - the system clock will again be more likely > accurate. > > This redundant time offset info can serve as human-readable > indication of absolute time, while the time zone name will indicate > the location. > > 2022-11-12 12:00+07 @!Asia/Singapore > > Org will calculate the internal time for both +07 offset and > Asia/Singapore time zone. If they do not match, Org will issue a > warning. The offset will still be preferred if we have to proceed. > > This can be useful when planning future meetings and sending Org file > with a timestamp to someone else, potentially with obsolete tzdb. > > |-----------------------------------| > | <end> | > |-----------------------------------| > > Apart from the ideas mentioned above, > https://www.loc.gov/standards/datetime/ contains a number of other > interesting ideas that may or may not be adapted by Org in future. > I will outline the ideas I find noteworthy to keep them in mind when > considering changing (including current changes) in the timestamp > syntax: > > 1. Reduced timestamp precision: > 1985-04-12 (day precision, time omitted; available in Org) > 1985-04 (month precision, day and time omitted, not available in Org) > 1985 (year precision) > > Current timestamp syntax proposal should not interfere. > > 2. Using "T" as date/time delimiter > 1985-04-12T23:20:30 (not supported by Org) > > 3. Using "/" for time intervals > 2004-02-01/2005-02-08 (not supported and incompatible with Org) > > 4. Seasons > 2001-21 (Spring, 2001; not supported by Org) > > 5. Approximate dates > 1984? (year uncertain) > 2004-06~ (year-month approximate) > 2004-06-11% (entire date (year-month-day) uncertain and approximate) > 2004-06?-11 (year and month uncertain) > 2004-?06-11 (just month uncertain) > > 6. Unspecified digits > 1985-04-XX (day unspecified; might be an interesting idea for > defining repeater intervals) > > 7. Open time intervals > 1985-04-12/.. (from 1985-04-12 to infinite) > 1985-04-12/ (from 1985-04-12 to unknown) > > 8. Negative calendar year > -1985 (note: an alternative could be allowing AD/BC) > > 9. Set of dates > [1667,1668,1670..1672] (one of) > {1667,1668,1670..1672} (all) > [1760-01,1760-02,1760-12..] > (similar to regexp [...] groups; not compatible with Org syntax, but > the idea could be interesting for repeater intervals)