3 ms·

Maybe a naive question but why wasn't the timestamp designed as seconds since the epoch with zero adjustments? Everything would be derived from that. I suppos

Maybe a naive question but why wasn't the timestamp designed as seconds since the epoch with zero adjustments? Everything would be derived from that. I suppose it would make some math more complex but overall it feels simpler.

growse 2y ago
With hindsight, we'd do lots of things differently :) I guess they just didn't foresee the problem, or misjudged the impact. I can imagine it being very "let's kick that problem down the road and just do a simple thing for now" approach.
- wat10000 2y ago
  UNIX systems at the time probably didn’t care about accuracy to the second being maintained over rare leap second adjustments. Random example, the wonderful RealTime1987A project (https://bmonreal.github.io/RealTime1987A/ https://bmonreal.github.io/RealTime1987A/) talks about detecting neutrinos from the supernova, and what information can be inferred from the timing of the detections. A major source of that data is the Super Kamiokande project. The data was recorded to tape by a PDP-11, timestamped by its local clock. That clock was periodically synced with UTC with a sophisticated high-tech procedure that consisted of an operator making a phone call to some time service, then typing the time into the computer. As such, the timestamps recorded by this instrument have error bars of something like +/- one minute. If that’s the sort of world you’re in, trying to account for leap seconds probably seems like a complete waste of effort and precious computer memory.
fragmede 2y ago
Arguably it's worse if 00:33 on 2024.12.26 has to get run through another function to get the true value of 2024.12.25 T 23:59. The problem is leap seconds. Software just wasn't designed to handle 86401 seconds in a day, and caused incidents at Google, Cloudflare, Quantus, and others. Worried that resolving all possible bugs related to days with 86401 seconds in them was going to be impossible to get right, Google decided to smear that leap second so that the last "second" isn't. And if you've not seen it, there's the falsehoods programmers believe about time article.
- quasarj 2y ago
  But that's not the case... the random-looking very-large value X has to go through a conversion function to get the true value of 2024.12.25 T 23:59, just like every other value. Surely nobody is just dividing the Unix time by 86400 like people keep suggesting? What kind of a hack would think they could do date math themselves?

growse 2y ago

With hindsight, we'd do lots of things differently :) I guess they just didn't foresee the problem, or misjudged the impact. I can imagine it being very "let's kick that problem down the road and just do a simple thing for now" approach.

wat10000 2y ago
UNIX systems at the time probably didn’t care about accuracy to the second being maintained over rare leap second adjustments. Random example, the wonderful RealTime1987A project (https://bmonreal.github.io/RealTime1987A/ https://bmonreal.github.io/RealTime1987A/) talks about detecting neutrinos from the supernova, and what information can be inferred from the timing of the detections. A major source of that data is the Super Kamiokande project. The data was recorded to tape by a PDP-11, timestamped by its local clock. That clock was periodically synced with UTC with a sophisticated high-tech procedure that consisted of an operator making a phone call to some time service, then typing the time into the computer. As such, the timestamps recorded by this instrument have error bars of something like +/- one minute. If that’s the sort of world you’re in, trying to account for leap seconds probably seems like a complete waste of effort and precious computer memory.

fragmede 2y ago

Arguably it's worse if 00:33 on 2024.12.26 has to get run through another function to get the true value of 2024.12.25 T 23:59. The problem is leap seconds. Software just wasn't designed to handle 86401 seconds in a day, and caused incidents at Google, Cloudflare, Quantus, and others. Worried that resolving all possible bugs related to days with 86401 seconds in them was going to be impossible to get right, Google decided to smear that leap second so that the last "second" isn't. And if you've not seen it, there's the falsehoods programmers believe about time article.

quasarj 2y ago
But that's not the case... the random-looking very-large value X has to go through a conversion function to get the true value of 2024.12.25 T 23:59, just like every other value. Surely nobody is just dividing the Unix time by 86400 like people keep suggesting? What kind of a hack would think they could do date math themselves?