Comment by LegionMammal978 | Hacker News Reader

Comment by LegionMammal978 | Hacker News Reader

Parent Full thread

LegionMammal978

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-e...

[1] https://tc39.es/proposal-temporal/docs/strings.html#iana-tim...

[2] https://tc39.es/proposal-temporal/docs/ambiguity.html#ambigu...

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?

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.

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)?

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.

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.

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.

Honestly, this applies to the entire rest of the thread too.

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.

Maybe

` 2030-07-01T18:00:00[!Local] `

Where no offset and the !Local tell the app to use OOB defined location?

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.

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...

> 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?

> Perhaps I’m missing something?

Yes, you’re missing something - geography. “Local time” doesn’t include a frame of reference. If you want to have a meaningful representation of local time you need syntax to specify where, probably Lat/Long.

Then, periodically, the computer can look up the lat/long to see what the rules are there for time, and compare vs the target time.

But even THAT doesn’t solve the problem, because you probably don’t want the computer in a tight loop of looking up location rules for time and checking time. But if you do it periodically then there is a nonzero chance that you will miss the event because the rules changed since the last check and the current check happened after the event.

And you can’t just use the city names for time zones (e.g. “Europe/London”) because only a very small number of places have such names, and because they really refer to a combination of time zone and DST rules, not to a city, they just choose representative cities.

Finally, ISO 8601 does support durations, which RFC 3339 does not, so ISO seems more useful in that regard, but durations are not relative to any epoch.

I agree on not including the offset.

However I'm saying that the solution should be radically different and much more user focused.

There is a difference between a description of when to capture a moment (which should favor the way the normal person describes moments) and an absolute moment event.

Except you don't even know if they in the future uses the same calendar.

We don't even know if the future can read or write in our commonly used alphabets.

Or maybe even time reverses course and runs backwards. See: PK Dick, Counter-Clock World, 1967.

Reply on news.ycombinator.com