4 ms·
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 i
by throwaway09223 5y ago
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.
- kstenerud 5y agoYes, 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.
- throwaway09223 5y agoWell, I guess we'll have to agree to disagree. 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.
- CameronNemo 5y agowith 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.
- kstenerud 5y agoWhat'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...