3 ms·

What's wrong with TAI? Using a date format for precise time types doesn't make much sense because human readable date formats are inherently tied to orbital me

What's wrong with TAI? 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.

kstenerud 5y ago
There are a few reasons: - 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).
- 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 ago
    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.
    - throwaway09223 5y ago
      Well, 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 ago
      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.
      - kstenerud 5y ago
        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...

kstenerud 5y ago

There are a few reasons: - 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).

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 ago
  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.
  - throwaway09223 5y ago
    Well, 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 ago
    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.
    - kstenerud 5y ago
      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...