Re: [POLL] Proposed syntax for timestamps with time zone info (was: [FEATURE REQUEST] Timezone support in org-mode datestamps and org-agenda)

[Christian Moe]

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)