> Time zone identifier instead of just a fixed offset (which are ambiguous for future events)
Time zone identifiers are not future-proof. As a concrete example imagine a fictitious country X with the largest city (not necessarily the capital) being Foo and a single time zone throughout the country. A natural time zone identifier would be something like `Region/Foo`. If a part of X switches to another time zone and Bar is the largest city in that region for whatever reason, there would be another time zone identifier `Region/Bar` assigned. You can't automatically determine which `Region/Foo` should be converted to `Region/Bar`. It is up to you to pick a strategy in such cases, but time zone identifiers themselves do not solve the ambiguity problem.
Besides from this false sense of security, time zone identifiers were not meant to be for general interchange and there are several understandable but problematic assignments. Baking them into a data structure format doesn't sound a good idea.
That's a valid scenario where time zone identifiers don't work well, but what's the alternative? A fixed offset is guaranteed to be wrong on DST switch, and that happens a lot more often than time zones splintering. I guess GPS coordinates would be more accurate, but then you have privacy concerns.
Fun fact: time zones are named after cities for robustness:
Country names are not used in this scheme, primarily because they would not be robust, owing to frequent political and boundary changes. The names of large cities tend to be more permanent. Usually the most populous city in a region is chosen to represent the entire time zone, although another city may be selected if it is more widely known, and another location, including a location other than a city, may be used if it results in a less ambiguous name.
You do need time zone identifiers or something like that, but they are not something you can blindly buy in. I mean, of course it would be great to see a semi-automated solution for that (for example, such a solution can automatically determine Region/Foo is split into Region/Foo and Region/Bar but nothing else)! But the time zone database doesn't provide anything like that, and a built-in support for time zone identifiers can hugely mislead users.
It seems like these problems with defining/describing timezones (i.e., temporal reference systems if you will) are similar to those of defining spatial reference systems. Spatial reference systems are fairly rigorously defined/described using both standard (e.g., WKT) and non-standard formats (PROJ strings, EPSG numbers). Is there something similar for temporal reference systems?
Time zones based upon anthropocentric concepts like countries have issues simply due to the realities of political changes. Entire countries and civilizations can come and go. The concept of even “common era” is a convention of convenience still based around a religious figure frankly, which is a sort of retcon given others through the same time period were likely measuring time in another coordinate system essentially.
A self defining and self describing set of measurements would help here but obviously bloats formats similar to how XML schemas become overly verbose and pedantic without adding clarity to the target audience.
So I agree that baking in a time zone is likely a bad idea but I have doubts we can do much better by trying to use another more absolute time coordinate system independent upon human civilization conventions.
Time zone identifiers are not future-proof. As a concrete example imagine a fictitious country X with the largest city (not necessarily the capital) being Foo and a single time zone throughout the country. A natural time zone identifier would be something like `Region/Foo`. If a part of X switches to another time zone and Bar is the largest city in that region for whatever reason, there would be another time zone identifier `Region/Bar` assigned. You can't automatically determine which `Region/Foo` should be converted to `Region/Bar`. It is up to you to pick a strategy in such cases, but time zone identifiers themselves do not solve the ambiguity problem.
Besides from this false sense of security, time zone identifiers were not meant to be for general interchange and there are several understandable but problematic assignments. Baking them into a data structure format doesn't sound a good idea.