4 ms·

This is the biggest reason why I had to develop a new time format for Concise Encoding :/ https://github.com/kstenerud/concise-encoding/blob/master/ce-structur

This is the biggest reason why I had to develop a new time format for Concise Encoding :/ https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#temporal-types https://github.com/kstenerud/concise-encoding/blob/master/ce... https://github.com/kstenerud/concise-encoding/blob/master/cte-specification.md#why-not-iso-8601-or-rfc-3339 https://github.com/kstenerud/concise-encoding/blob/master/ct... 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).

kortex 5y ago
I was going to give you the usual "now there are 15 different standards" but this is actually really well thought out. How does it handle leading zeros in the year, like Long Now likes to do? https://blog.longnow.org/02013/12/31/long-now-years-five-digit-dates-and-10k-compliance-at-home/ https://blog.longnow.org/02013/12/31/long-now-years-five-dig...
- kstenerud 5y ago
  For the text variant, it just parses the year field as an integer, so leading zeroes would generate the same year value as if you'd omitted them.
  - kortex 5y ago
    Nice, that's the parsimonious way to handle it. I'm really digging this system in general. I hope it gets more traction.
    - dmurray 5y ago
      On the other hand, valid data may now be unreasonably long. What if someone gives you a string that starts with 10^12 leading zeros?
      - kstenerud 5y ago
        This is where security and limits comes in: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#security-and-limits https://github.com/kstenerud/concise-encoding/blob/master/ce...
throwaway09223 5y ago
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.

kortex 5y ago

I was going to give you the usual "now there are 15 different standards" but this is actually really well thought out. How does it handle leading zeros in the year, like Long Now likes to do? https://blog.longnow.org/02013/12/31/long-now-years-five-digit-dates-and-10k-compliance-at-home/ https://blog.longnow.org/02013/12/31/long-now-years-five-dig...

kstenerud 5y ago
For the text variant, it just parses the year field as an integer, so leading zeroes would generate the same year value as if you'd omitted them.
- kortex 5y ago
  Nice, that's the parsimonious way to handle it. I'm really digging this system in general. I hope it gets more traction.
  - dmurray 5y ago
    On the other hand, valid data may now be unreasonably long. What if someone gives you a string that starts with 10^12 leading zeros?
    - kstenerud 5y ago
      This is where security and limits comes in: https://github.com/kstenerud/concise-encoding/blob/master/ce-structure.md#security-and-limits https://github.com/kstenerud/concise-encoding/blob/master/ce...

throwaway09223 5y ago

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.