Re^2: A Very Fast 64–Bit Date Algorithm

You might also watch Tom Scott's video "The problem with time & timezones".

Thanks. That was interesting to listen to. I had realized time was a complex task, but I was off by about three or four orders of magnitude regarding that complexity. It's very far from a calculation and more like a detailed set of lookup tables combined with a few algorithms.

Comment on Re^2: A Very Fast 64–Bit Date Algorithm

Replies are listed 'Best First'.
Re^3: A Very Fast 64–Bit Date Algorithm by cavac (Prior) on Dec 09, 2025 at 15:13 UTC
Yeah, and Tom barely scratches the surface. Just handling the occasional leap second is quite the feat and can push all kinds of systems over the cliff. Just look at Five different ways to handle leap seconds with NTP. Imagine, for example, you are running a livestream (audio, video, doesn't matter). Syncronization depends on knowing the server time and the client time. If they are off, the stream might skip (forwards or backwards). If time slewing is in effect, audio might fail altogether, because the sample rate of audio (as is handled on the network and in software based on system time) might differ from the sample rate in your hardware (as defined by some crystal oszilator). And if time slewing is NOT used, the livestream may fall altogether, because the software might not be able to handle 61 seconds in a minute and crash with an error. More reads, because, yes, handling leap seconds is complicated, expensive, and a science in itself: Google: Leap smear It's Time to Ditch the Leap Second: The Devastating Effect of Adding Just 1 Second The Leap Second’s Time Is Up: World Votes to Stop Pausing Clocks Towards a consensus on a continuous coordinated universal time TECHNICAL ASPECTS OF LEAP SECOND PROPAGATION AND EVALUATION XKCD Leap Smearing And this is just one small aspect of horology (or chronometry). Remember, if you want exact time calculations, you even have to keep track of earthquakes: (NASA scientists) also found the earthquake decreased the length of day by 2.68 microseconds. PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP Also check out my sisters artwork and my weekly webcomics	[reply]

Replies are listed 'Best First'.

Re^3: A Very Fast 64–Bit Date Algorithm
by cavac (Prior) on Dec 09, 2025 at 15:13 UTC

Yeah, and Tom barely scratches the surface. Just handling the occasional leap second is quite the feat and can push all kinds of systems over the cliff. Just look at Five different ways to handle leap seconds with NTP.

Imagine, for example, you are running a livestream (audio, video, doesn't matter). Syncronization depends on knowing the server time and the client time. If they are off, the stream might skip (forwards or backwards).

If time slewing is in effect, audio might fail altogether, because the sample rate of audio (as is handled on the network and in software based on system time) might differ from the sample rate in your hardware (as defined by some crystal oszilator).

And if time slewing is NOT used, the livestream may fall altogether, because the software might not be able to handle 61 seconds in a minute and crash with an error.

More reads, because, yes, handling leap seconds is complicated, expensive, and a science in itself:

And this is just one small aspect of horology (or chronometry). Remember, if you want exact time calculations, you even have to keep track of earthquakes: (NASA scientists) also found the earthquake decreased the length of day by 2.68 microseconds.

PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP
Also check out my sisters artwork and my weekly webcomics

[reply]