Since Time::Piece always works from an epoch time, the algorithm could help it assuming it doesn't slow down also getting hours, minutes and seconds.
That said, you could get far larger savings by converting Time::Piece to C.
| [reply] |
Almost anything in perl is going to have costs that dwarf the improvements he made there. But in answer to your question: look at the module sources and see what you think? | [reply] |
Hmm, the slowdown for generic date/time calculations doesn't really come from the algorithm itself, but from the idiosyncracies of humans. Timezones shift, date calculations get all kinds of weird updates, there is all the summer/winter time kerfuffle, leap seconds, etc.
To name one of my favourite examples, the algorithm you posted will most likely fail for Samoa dates because of 2011. In 2011, Samoa skipped the 30th of December entirely, it went directly from the 29th to the 31st. That's why date/time modules are a mess of spagetti code that does all kinds of (slow'ish) lookups in many different tables, and some expensive calculations.
With date and time calculations, it's usually more important to get them correct then to get them fast. Some timestamps might even be impossible to get correct precisely, namely those in the future. A politically motivated change to a timezone here, a drop of daylightsaving time there, an updated Bulletin C thrown in the mix and your predicted timestamp completely goes down the drain...
You might also watch Tom Scott's video "The problem with time & timezones".
| [reply] |
| [reply] |
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.
| [reply] |