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".
In reply to Re: A Very Fast 64–Bit Date Algorithm
by cavac
in thread A Very Fast 64–Bit Date Algorithm
by mldvx4
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |