Seconds since epoch requires careful and precise handling of datatypes and assumptions. This works great inside a system where that can be managed but for the purpose of exchange between systems the ISO formats contain all relevant information. Either side can use a library to parse the string into their local representation.
Comprehension by extraterrestrial life is a localization problem.
I'm not sure I understand. How is this different from any other quantity with an associated unit? What's the possible failure mode here, interpreting the "created_time_us" field as a distance in km instead of a timedelta in microseconds?
Is the unit seconds or microseconds? How are leap seconds handled? What base type is used? Integer, number, or float? How many bits? What is the precision? What is the CPU architecture? Is it signed? How should overflows be handled?
You can store weight as ohms of resistance on a load cell. But if you want to share that data you need to either normalize the number to a mutually understood unit or provide detailed information about your scale.
Aside from the obvious issue with engineering, physics, etc.
A unix second is allowed to be different from a "real" elapsed second.
The unix day has 86400 "unix seconds" which are actually 86401 real seconds (for days with added leap seconds).
Any application logging real world events against unix time will screw up velocities, force, energy, etc when computing "instrument reading" per "unix second".
It might not matter to most people but it's an issue for surveyors, geophysicists, astrophysicists, engineers, etc.
> Any application logging real world events against unix time will screw up velocities, force, energy, etc when computing "instrument reading" per "unix second".
That is a fair point for situations that depend on short term observations. But, UTC has the same issues there as Unix epoch. I think it is a valid edge case but if you are doing, say, GPS based speed calc I would wager you are already pulling your time reference from a low level source that you can depend on will be running steadily for the X minutes/hours you need it.
Sure, this is what responsible STEM people do for any time lapsed measurements, be those position, nine axis magnetic field recordings, gravity, radiometrics, microwave return, etc - they use an independant epoch based clock source that counts true lapsed time rather than conventional human time.
Point being, it's an area of UnixTime that many overlook - to date, since the 1980s I've had long term multichannel data aquisition running throughout every leap second adjustment which would have had data glitches had the time channel been UnixTime, UTC, etc.
Comprehension by extraterrestrial life is a localization problem.