6 ms·

I have often wondered why dates are so complicated. `timespec`, `timeval`, `tm`? Why not use a 64bit unsigned int to describe the time in TAI [1] (no leap secon

I have often wondered why dates are so complicated. `timespec`, `timeval`, `tm`? Why not use a 64bit unsigned int to describe the time in TAI [1] (no leap seconds, trivial computation of difference between points in time) in nanoseconds? That would give us 585 years, so our ancestors can deal with it. [1] https://en.wikipedia.org/wiki/International_Atomic_Time https://en.wikipedia.org/wiki/International_Atomic_Time

MiddleEndian 5y ago
>ancestors What kind of clock is this!?
- donquichotte 5y ago
  Oops, I meant descendants, and now I am giggling uncontrollably.
  - tsimionescu 5y ago
    Reminded me of Terry Pratchett' retroannual (?) crops, which would be ready for harvest a few years before planting, putting a lot of responsibility on the farmer not to forget to plant what he'd already eaten.
    - kwhitefoot 5y ago
      Not to mention reannual vines which are used to make wine that gives you a hangunder before you have drunk it. https://wiki.lspace.org/Hangunder https://wiki.lspace.org/Hangunder
MaulingMonkey 5y ago
Well, if you ignore everything but "uint64_t counter go brrrr", it turns out dates and times are pretty easy. But even a uint64_t TAI counter is incredibly underspecced. How do you handle clock drift when your local counter gets out of sync with TAI - is the counter monotonically increasing, or will time potentially replay, with all the issues that entails? What if the local clock was off by hours, days, even years? Will you clock smear if the correction is small? Within what bounds? GPS satellites will still need to correct for relativistic effects for accurate position measurement. TAI nanoseconds since epoch will still need to be converted to and from human readable formats - doing so correctly touches on geopolitical issues (DST, timezones, leap seconds, recognized soverigenty of contested borders, etc.) I also don't schedule relative to TAI. Suppose I schedule lunch for 1PM. What timezone? Will it track DST on reoccurences? If I move timezones, is 1PM relative to me, my device, or perhaps the device of my coworker who remains behind in the original timezone, with whom I've coordinated lunch with so we have an opportunity to chat? It turns out this is basically a natural language parsing / DWIM issue. Storing this 1PM task in TAI isn't right, even if it's not reoccuring - if I change timezones, I'm likely to be changing when my schedule is in "absolute" terms, to the degree that's even a thing, and when DST does or doesn't kick in, that also changes when my schedule is in "absolute" terms. Dates are complicated because everything is relative. And relative to what? Well, that's suprisingly vague, even in the minds of the people using them. Between conversion bugs, ambiguous inputs, and both relativity and clock issues making any notion of absolute time an absolute farce not just in theory but in practice... dates and times end up complicated. Is it 1:05 AM, 1:06 AM, or 1:07 AM? Depends on which clock in eyesight I'm looking at, and I'm just in my apartment.

MiddleEndian 5y ago

>ancestors What kind of clock is this!?

donquichotte 5y ago
Oops, I meant descendants, and now I am giggling uncontrollably.
- tsimionescu 5y ago
  Reminded me of Terry Pratchett' retroannual (?) crops, which would be ready for harvest a few years before planting, putting a lot of responsibility on the farmer not to forget to plant what he'd already eaten.
  - kwhitefoot 5y ago
    Not to mention reannual vines which are used to make wine that gives you a hangunder before you have drunk it. https://wiki.lspace.org/Hangunder https://wiki.lspace.org/Hangunder

MaulingMonkey 5y ago

Well, if you ignore everything but "uint64_t counter go brrrr", it turns out dates and times are pretty easy. But even a uint64_t TAI counter is incredibly underspecced. How do you handle clock drift when your local counter gets out of sync with TAI - is the counter monotonically increasing, or will time potentially replay, with all the issues that entails? What if the local clock was off by hours, days, even years? Will you clock smear if the correction is small? Within what bounds? GPS satellites will still need to correct for relativistic effects for accurate position measurement. TAI nanoseconds since epoch will still need to be converted to and from human readable formats - doing so correctly touches on geopolitical issues (DST, timezones, leap seconds, recognized soverigenty of contested borders, etc.) I also don't schedule relative to TAI. Suppose I schedule lunch for 1PM. What timezone? Will it track DST on reoccurences? If I move timezones, is 1PM relative to me, my device, or perhaps the device of my coworker who remains behind in the original timezone, with whom I've coordinated lunch with so we have an opportunity to chat? It turns out this is basically a natural language parsing / DWIM issue. Storing this 1PM task in TAI isn't right, even if it's not reoccuring - if I change timezones, I'm likely to be changing when my schedule is in "absolute" terms, to the degree that's even a thing, and when DST does or doesn't kick in, that also changes when my schedule is in "absolute" terms. Dates are complicated because everything is relative. And relative to what? Well, that's suprisingly vague, even in the minds of the people using them. Between conversion bugs, ambiguous inputs, and both relativity and clock issues making any notion of absolute time an absolute farce not just in theory but in practice... dates and times end up complicated. Is it 1:05 AM, 1:06 AM, or 1:07 AM? Depends on which clock in eyesight I'm looking at, and I'm just in my apartment.