Maybe
` 2030-07-01T18:00:00[!Local] `
Where no offset and the !Local tell the app to use OOB defined location?
` 2030-07-01T18:00:00[!Local] `
Where no offset and the !Local tell the app to use OOB defined location?
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
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...
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?
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.
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.