4 ms·

There's currently a draft document for such a format [0], called IXDTF (the Internet Extended Date/Time Format). It allows you to specify a timezone (as a tz na

There's currently a draft document for such a format [0], called IXDTF (the Internet Extended Date/Time Format). It allows you to specify a timezone (as a tz name) in brackets following an RFC 3339 string. To give a local time, you have to specify your best estimate of the UTC offset alongside the bracketed timezone. For instance, "2030-07-01 18:00:00 Europe/London" would be "2030-07-01T18:00:00+01:00[Europe/London]". If the UK changes its rules before that time, then the timestamp becomes "inconsistent" (see section 3.4). The behavior on an inconsistent timestamp is left for the application to decide, but if a ! character is included within the brackets before the timezone name, then it's at least obligated to detect the problem instead of blindly following the UTC offset: > In case of inconsistent time-offset and time zone suffix, if the critical flag is used on the time zone suffix, an application MUST act on the inconsistency. If the critical flag is not used, it MAY act on the inconsistency. Acting on the inconsistency may involve rejecting the timestamp, or resolving the inconsistency via additional information such as user input and/or programmed behavior. This extended timestamp format is used in the proposed Temporal library for JavaScript [1] (though I'm not sure if it supports the ! character). The ZonedDateTime.from() parsing function [2] takes an optional "offset" parameter to allow the user to control which part of an inconsistent timestamp takes precedence. It also supports simply omitting the UTC offset and using only the timezone, but it warns that this is ambiguous for times in the repeated hour during a DST transition. [0] https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-09.html https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e... [1] https://tc39.es/proposal-temporal/docs/strings.html#iana-time-zone-names https://tc39.es/proposal-temporal/docs/strings.html#iana-tim... [2] https://tc39.es/proposal-temporal/docs/ambiguity.html#ambiguity-caused-by-permanent-changes-to-a-time-zone-definition https://tc39.es/proposal-temporal/docs/ambiguity.html#ambigu...

seabass-labrax 3y ago
That's an excellent idea, and one which I should hope to implement in my calendaring software if it is accepted. Are you one of the authors?
- LegionMammal978 3y ago
  No, I'm not affiliated with the authors, I just recalled seeing the extended syntax when I looked into Temporal's features a while back.
djbusby 3y ago
Maybe ` 2030-07-01T18:00:00[!Local] ` Where no offset and the !Local tell the app to use OOB defined location?
- ilyt 3y ago
  maybe ~ ? 2030-07-01T18:00:00~BTC 2030-07-01T18:00:00~CEST 2030-07-01T18:00:00~Local 2030-07-01T18:00:00~Europe/Warsaw to signify it is not a constant point in time but timezone-at-the-time dependent.
  - mjevans 3y ago
    The issue is, what do you mean? This time description in the indicated timezone, at the instant it is correct? (Ignore updates, I mean the time I said. E.G. The doors open at 8am every day.) An indicated end of a duration, such as the period of time a mass of decaying radio-isotopes are valid for the sensor during? (Offhand, no consumer equipment comes to mind, but for an extremely sensitive calibrated sample it could matter and this is a contrived example.) Exact moment in monotonic time. (What about stretchy leap seconds too?) Something between the two extremes? Most humans probably want a default of something like... "Looser more common use time unless I get more specific." So if a TZ is included, it isn't a fixed moment, but whatever specifier is the valid moment as that moment passes. Convert it to an absolute monotonic value at that time to record the event and not just the specification of when to capture the event's passing. E.G. Unix time Epoch was 1970-01-01 00:00:00~Z with an absolute reference value of 0s DATE RoundedHour~US.EST => Actually is EDT but most people don't use that notation, and congress changed when DST happens yet again without abolishing it too, and this happened last year before the change but the event did run from Noon to 9PM with these event moment second values...
    - klabb3 3y ago
      > The issue is, what do you mean? It would simply mean the time which is intended. It’s true that the instant isn’t known until it happens (or however much leeway precedes a TZ change). It’s generally always better to record intent, than to be smart and translate inputs to something else. To map to a specific instant in UTC time, you use the string plus a db. The db can change in the future, and that’s ok. You simply update in the presentation layer in case you have any “2h left” strings or calendar entries. Note you should NOT store the mapped instance in a db before the event has occurred (and even then it’s unnecessary since it’s fixed). I really don’t like the “inconsistent” mutable property and agree with parent that offset should not be part of the format. That would make it extremely easy to overlook or misuse. Perhaps I’m missing something?
bboygravity 3y ago
tz name? Sounds super brittle to me when looking at history. So what happens when a timezone name changes? Say Manila timezone changes names to New Beijing timezone in the next 10 years (fictive example)?
- brongondwana 3y ago
  If the timezone name changes, chances are I no longer want to meet at 6pm in London in 10 years' time without double-checking a few things.
  - trifurcate 3y ago
    Honestly, this applies to the entire rest of the thread too.
    - kevincox 3y ago
      No? If the UK decides to stop doing DST or synchronize when they do DST with North America I still want to have my meeting at 6pm local time. Not have that meeting be 5pm or 7pm for some reason.
- TheDong 3y ago
  tzdata does not remove timezone names. If the 'Asia/Manila' timezone changes to the 'Asia/Shanghai' timezone, the old timezone will still exist, but a rule will be added to indicate the change. The tz name here is a specific name in the tzdata database, so it's quite easy for that database to never remove any entries, but to rather deprecate them or link them to new ones, if appropriate.
  - bboygravity 3y ago
    Yes and then you'll have old source code that still uses the old names to indicate time-zones and newer source code that refers to all the newest names of time-zones.

seabass-labrax 3y ago

That's an excellent idea, and one which I should hope to implement in my calendaring software if it is accepted. Are you one of the authors?

LegionMammal978 3y ago
No, I'm not affiliated with the authors, I just recalled seeing the extended syntax when I looked into Temporal's features a while back.

djbusby 3y ago

Maybe ` 2030-07-01T18:00:00[!Local] ` Where no offset and the !Local tell the app to use OOB defined location?

ilyt 3y ago
maybe ~ ? 2030-07-01T18:00:00~BTC 2030-07-01T18:00:00~CEST 2030-07-01T18:00:00~Local 2030-07-01T18:00:00~Europe/Warsaw to signify it is not a constant point in time but timezone-at-the-time dependent.
- mjevans 3y ago
  The issue is, what do you mean? This time description in the indicated timezone, at the instant it is correct? (Ignore updates, I mean the time I said. E.G. The doors open at 8am every day.) An indicated end of a duration, such as the period of time a mass of decaying radio-isotopes are valid for the sensor during? (Offhand, no consumer equipment comes to mind, but for an extremely sensitive calibrated sample it could matter and this is a contrived example.) Exact moment in monotonic time. (What about stretchy leap seconds too?) Something between the two extremes? Most humans probably want a default of something like... "Looser more common use time unless I get more specific." So if a TZ is included, it isn't a fixed moment, but whatever specifier is the valid moment as that moment passes. Convert it to an absolute monotonic value at that time to record the event and not just the specification of when to capture the event's passing. E.G. Unix time Epoch was 1970-01-01 00:00:00~Z with an absolute reference value of 0s DATE RoundedHour~US.EST => Actually is EDT but most people don't use that notation, and congress changed when DST happens yet again without abolishing it too, and this happened last year before the change but the event did run from Noon to 9PM with these event moment second values...
  - klabb3 3y ago
    > The issue is, what do you mean? It would simply mean the time which is intended. It’s true that the instant isn’t known until it happens (or however much leeway precedes a TZ change). It’s generally always better to record intent, than to be smart and translate inputs to something else. To map to a specific instant in UTC time, you use the string plus a db. The db can change in the future, and that’s ok. You simply update in the presentation layer in case you have any “2h left” strings or calendar entries. Note you should NOT store the mapped instance in a db before the event has occurred (and even then it’s unnecessary since it’s fixed). I really don’t like the “inconsistent” mutable property and agree with parent that offset should not be part of the format. That would make it extremely easy to overlook or misuse. Perhaps I’m missing something?

bboygravity 3y ago

tz name? Sounds super brittle to me when looking at history. So what happens when a timezone name changes? Say Manila timezone changes names to New Beijing timezone in the next 10 years (fictive example)?

brongondwana 3y ago
If the timezone name changes, chances are I no longer want to meet at 6pm in London in 10 years' time without double-checking a few things.
- trifurcate 3y ago
  Honestly, this applies to the entire rest of the thread too.
  - kevincox 3y ago
    No? If the UK decides to stop doing DST or synchronize when they do DST with North America I still want to have my meeting at 6pm local time. Not have that meeting be 5pm or 7pm for some reason.
TheDong 3y ago
tzdata does not remove timezone names. If the 'Asia/Manila' timezone changes to the 'Asia/Shanghai' timezone, the old timezone will still exist, but a rule will be added to indicate the change. The tz name here is a specific name in the tzdata database, so it's quite easy for that database to never remove any entries, but to rather deprecate them or link them to new ones, if appropriate.
- bboygravity 3y ago
  Yes and then you'll have old source code that still uses the old names to indicate time-zones and newer source code that refers to all the newest names of time-zones.