You're conflating two separate use cases. The point of the numerical-offset notation is exactly to denote a fixed point in time.
For the birthday party example: it's not a given that I want to reschedule it when the local time zone changes (maybe I want to meet before sundown so we can sit outside? in that case, I would want to adjust the local time, keeping the solar timethe same). Sometimes of course, it is desirable (think of the opening hours of a shop, for example), but that's a separate use case.
Similarly with online events involving international guests: if you move an event to keep the local time unchanged, this change might create conflicts on other people's calendars. It's not necessarily the desired outcome.
Another problem with including a time zone name is that not everybody has the same version of the time zone database. At worst, that means that different people will have different interpretations of which point in time is being described. At best, the result will only be eventually consistent.
Exactly. (Fixed objective time) -> (current subjective time) is a problem with enough nuances that you probably don't want your format making assumptions for you.
The international online-meeting corner case is interesting but I think you’re off the mark for the most common use case for these kinds of human readable time stamps: the local event begins when the local calendar shows the given date, and the local wall clock shows that particular time.
My birthday party begins next year on May 1st when both our Siberian clocks say it is 4pm.
> The point of the numerical-offset notation is exactly to denote a fixed point in time.
Then why support timezones at all? UTC-only is a much simpler way to denote fixed points in time; symbolic timezones are needed when you want to denote a human-friendly local timestamp. Numerical offsets are the worst of both worlds.
ISO 8601 and RFC 3339 are only useful for times in the past (which works fine for most internet protocols because they're only interested in recording events).
Using a date format for precise time types doesn't make much sense because human readable date formats are inherently tied to orbital mechanics[1] (days) and social constructs (timezones, calendars, laws, etc). Better to just record seconds from an epoch.
I see you mention leap seconds in your specification, but you don't address how to handle time in the future given that leap seconds can't be predicted more than 6mo in advance. This is a key feature of TAI -- no synchronization to earth's orbital mechanics. No leap seconds to keep the sun overhead at noon. This means your time spec will likely be off by seconds when using dates more than 6mo out. It seems like your format is also only useful for recording past dates.
[1] TAI is still tied to earth's frame of reference, of course. At some point when we get more serious about space, timestamps will need to include location and velocity. This is already a problem even on the scale of earth satellites and I don't think anyone's yet created a standard.
- The text format is designed for human reading and input. Nobody is going to understand TAI, or bother to look it up. They're going to enter time like they see on their clock.
- Special time representations like TAI require a bunch of complicated machinery to convert to/from a human-friendly format. It's complicated, requires regular maintenance, and implementations have varying levels of buggy. Keeping it human-friendly in the first place eliminates this whole class of problems.
- Leap seconds are already a thing because of the above two reasons, and they're not going away since we're not going to change humanity's understanding of time to something more precise.
We're perfectly capable of handling future dates beyond 6 months without using TAI (and keeping our clocks in sync well enough to be on time).
The special representation isn't TAI (seconds from epoch), the complex and special representations are the human readable formats. It's the human formats that incorporate intractable aspects of solar mechanics, law, and geography. TAI is the simple answer here.
It looks like you have a human readable (CTE) and binary format (CBE), and you use human-style formatting for the computer readable binary format. This seems incongruous to say the least, especially when I look at how you're representing other numeric types.
While human readable formats are complex, there are standard functions which generate them from epoch time. It's trivial to do this in a display layer, and strongly recommended architecturally speaking.
Also, leap seconds do go away if you use TAI. That's the entire point of TAI. Leap seconds are a display layer issue, just like time zones. They can be applied when translating an epoch to a localized format.
You cannot have seconds-level granularity with the way you've designed your time format. Sorry, but this is just a fact.
Yes, the "simpler" representation is TAI, but we still live in a human world, and with humans entering and reading the data we must conform to their ways in some things.
The binary and text encodings both store in Gregorian so that codecs don't have the added responsibility of converting between representations (keeps the implementations simple).
TAI is like lye: useful, but not meant to be handled by humans. And since this format is designed for human usability, human time wins the day.
When I look at human readable logfiles I see a trend towards using epoch seconds for exactly these reasons. It's so easy to convert, it outweighs the anti-usability aspects inherent in formatted strings. I've converted all my own human readable file formats to epoch times for exactly these reasons and my customers seem to strongly prefer it.
with humans entering and reading the data we must conform to their ways in some things
I don't understand what is stopping you from converting from tai to human readable and vice versa at the form/input and display/output layers, respectively.
What's stopping me is that time conversion is complex and incredibly difficult to get right. In order for a format to be successful, it must be usable on all platforms big and small, and across all programming languages. The more complex the task of implementing the format, the less likely it is to be successful.
TAI conversions are not equally available or of the same quality on all platforms and technologies, whereas Gregorian time is available pretty much everywhere and is well tested, robust, and easy to use (relatively speaking. Time is never easy).
If it turns out in future that I've made a serious blunder with this policy, I could just add a new type "TAI time" and bump the Concise Encoding spec version (Concise Encoding documents all specify which version of the spec they adhere to). There are still about 30 or so RESERVED type slots in the binary spec so we're not about to run out. We then get the type, just a little late. The alternative is that I make the format needlessly complicated by pre-emptively adding TAI, and risk destroying its adoption. Being right doesn't mean success...
Every year when DST ends, there are two hours during which the locale name based time is not unique since it could be both shortly before or after the time got turned back.
But beside that this would make sense when everyone involoved is living in the same timezone, but when coordinating internationally (which tends to be the main focus when the ISO is involved) we really do not want such changes to happen automatically. Everyone in the local timezone is likely to be aware of time changes so they know they have to adapt, but everyone in another timezone might have almost no way of knowing. For them, an event starting at a different (UTC) time is a rescheduling, no matter if it is caused by some timezone adjustment or not. So hiding this behind some tzdb change instead of sending out new dates would most likely mean that they appear at the wrong time.
Also including offsets ensures that the person writing the time knows the right offset. In the last year, I had quite some meetings where the host wanted to be nice and send the time in the local timezone for every participant. Since only timezone names and no offsets were included and the host mostly assumed that their local DST rules apply globally, this resulted in a giant mess. Especially after people informed them about errors, so the times switched back and forth between times assuming DST or not assuming DST. Without seeing the offset, there was no way of knowing which time was actually intended. If a UTC offset is given, most local people can relatively easily verify that it is the expected offset but even more importantly, you can independently convert it to the right zone no matter what the author thought.
I guess we could just put the lat/long and let people figure it out? But that still doesn't fix the time when the time zone does change... So using UTC is a simple fix
UTC doesn’t fix anything if you meant 6pm my local time on that day, come hell or high water.
Eg: Work at the local library is always 9 to 5 (again “local time”) and you mean precisely one hour after work lets up, regardless of whatever daylight savings or time zone changes occur between now and then.
You need to use either a naive date-time representation coupled with the additional context (“my time”) or use something like lat/long. Or you’re lucky and you live in or near enough to a major metropolis that has its own TZDB entry and it’s virtually impossible for your local time to diverge from that TZ, so you can use that instead (eg you live just outside NYC proper so you use America/New_York as your time zone).
Your example alludes to why there will always be a rift between UTC and local representations. Unless your system can understand "one hour after I end work for the day" correctly, any representation of that time will be subject to not just local timezones changes, but local work conditions for one or a few people (otherwise it can't be assumed a single time instance).
One is a a representation stripped of most ornamentation to be universally agreed upon, the other is a representation with many additional layers of context so it's locally understood.
There will likely always be a trade off between these, as a universal time is useful in all cases for only a small group of people, while a local time quickly loses relevance out of a local context.
One thing has nothing to do with the other. Timestamps are intended to simply record what the time is in a given place - not to telegraph expectations about local business hours.
China has one official time zone that covers five geographical time zones. Tell me, exactly how does saying "It's 6PM in China" tell me anything useful about the local library? You have to go to a local website and find out what time "in that part of China" the library is open. The timezone was never intended to express that.
Meh. You live in Gary, IN and you specify the birthday party as 2022-05-01T16:00 America/Chicago but your state representatives lobby to stop using Chicago time because remote work obviated that need and suddenly you’re actually supposed to be using America/Indiana/Indianapolis as your TZ.
It’s ugly whatever you do, unless you use coordinates to specify your time zone (then it’s just hell to decode).
2022-05-01T16:00+1000
…but tomorrow’s government abolishes daylight savings time, your birthday event has to change to:
2022-05-01T16:00+0900.
If you’d just said:
2022-05-01T16:00 Asia/Eastern_Siberia
…you’d be fine and everyone will show up at the right time.