Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Fast 64-Bit Date Algorithm (30–40% faster by counting dates backwards)

benjoffe.com

Post reply on HN
Print view View original

61–70 of 100 posts

Re: A Fast 64-Bit Date Algorithm (30–40% faster by counting dates backwards)

#61

Post by Dylan16807 »

Mikhail_Edoshin wrote: post #29
zokier wrote: post #25

Earlier quoted context omitted.

not completely coincidentally, March was also the first month of the year in many historical calendars. Afaik that also explains why the month names have offset to them (sept, oct, nov, dec) edit: I just love that there are like 5 different comments pointing out this same thing

I've read that not only March was the first month, but the number of months was only ten: winter months did not need to be counted because there was no agricultural work to be done (which was the primary purpose of the calendar). So after the tenth month there was a strange unmapped period.

How do you figure out it's March 1 if you're not counting days?

Re: A Fast 64-Bit Date Algorithm (30–40% faster by counting dates backwards)

#62

Post by stouset »

jayknight wrote: post #59
stouset wrote: post #58

Earlier quoted context omitted.

I thought Sept, Oct, Nov, and Dec were shifted by the addition of July (Julius) and August (Augustus)?

That's a common misconception. Those were just renamed for the Caesars. January and February we added, before that there was just a gap in the winter.

TIL thanks!

Re: A Fast 64-Bit Date Algorithm (30–40% faster by counting dates backwards)

#64

Post by pbhjpbhj »

jcranmer wrote: post #44
d--b wrote: post #24

Earlier quoted context omitted.

IIRC, it's also why the leap day was set to Feb 29th in the first place. At the time (romans?) the year started March 1st. In case someone was wondering why in the world someone said we should add a day to the second month of the year...

The calendar was regularized to include a leap day during the reign of Julius Caesar (hence the name "Julian calendar"), which would have been 45 BC. The Roman calendar moved to January as the first month of the year in 153 BC, over a hundred years before the leap day was added. The 10-month calendar may not have even existed--we see no contemporary evidence of its existence, only reports of its existence from centur…

Wikipedia gives 3 dates for January being the first month, either (approx) 700, 450, 150 BCE.

It's fair to say January was the first month of the Roman calendar; despite it having formerly been March.

Re: A Fast 64-Bit Date Algorithm (30–40% faster by counting dates backwards)

#65

Post by toast0 »

Findecanor wrote: post #42

TIL that Unix Time does not count leap seconds. If it did, it wouldn't have been possible to write routines that are this fast.

If Unix Time enumerated leap seconds, you couldn't convert future timestamps into localized times.

Re: A Fast 64-Bit Date Algorithm (30–40% faster by counting dates backwards)

#66

Post by aw1621107 »

ape4 wrote: post #63

Perhaps nicer to avoid the comment and write: const C1 = 505054698555331 // floor(2^64*4/146097) as constexpr int C1 = floor(2^64*4/146097);

std::floor was made constexpr in C++23, which is pretty recent as far as C++ standards go. It's possible the author didn't think using C++23 was worth the constraints it places on who could use the code.

Re: A Fast 64-Bit Date Algorithm (30–40% faster by counting dates backwards)

#67

Post by eru »

Dylan16807 wrote: post #61
Mikhail_Edoshin wrote: post #29

Earlier quoted context omitted.

I've read that not only March was the first month, but the number of months was only ten: winter months did not need to be counted because there was no agricultural work to be done (which was the primary purpose of the calendar). So after the tenth month there was a strange unmapped period.

How do you figure out it's March 1 if you're not counting days?

Equinox or something like that?

Re: A Fast 64-Bit Date Algorithm (30–40% faster by counting dates backwards)

#68

Post by eru »

jcranmer wrote: post #44
d--b wrote: post #24

Earlier quoted context omitted.

IIRC, it's also why the leap day was set to Feb 29th in the first place. At the time (romans?) the year started March 1st. In case someone was wondering why in the world someone said we should add a day to the second month of the year...

The calendar was regularized to include a leap day during the reign of Julius Caesar (hence the name "Julian calendar"), which would have been 45 BC. The Roman calendar moved to January as the first month of the year in 153 BC, over a hundred years before the leap day was added. The 10-month calendar may not have even existed--we see no contemporary evidence of its existence, only reports of its existence from centur…

Btw, the Romans had leap days before Julius Caesar, but they were added ad hoc by the Pontifex Maximus.

Caesar happened to be the Pontifex Maximus (an office you hold for life once elected to), but he wasn't in Rome much to do that job. So after he came back from hanging out with Cleopatra in Egypt he came back and set the calendar on auto-pilot.

Re: A Fast 64-Bit Date Algorithm (30–40% faster by counting dates backwards)

#69

Post by CodesInChaos »

aw1621107 wrote: post #66
ape4 wrote: post #63

Perhaps nicer to avoid the comment and write: const C1 = 505054698555331 // floor(2^64*4/146097) as constexpr int C1 = floor(2^64*4/146097);

std::floor was made constexpr in C++23, which is pretty recent as far as C++ standards go. It's possible the author didn't think using C++23 was worth the constraints it places on who could use the code.

That's a mathematical expression, not a C++ expression. And floor here isn't the C++ floor function, it's just describing the usual integer division semantics. The challenge here is that you need 128-bit integers to avoid overflowing.

Re: A Fast 64-Bit Date Algorithm (30–40% faster by counting dates backwards)

#70

Post by Tor3 »

jandrese wrote: post #16
fnordsensei wrote: post #10

Earlier quoted context omitted.

Wouldn’t it be accurate for that as well? Unless we change to base 10 time units or something. Then we all have a lot of work to do. But if it’s just about starting over from 0 being the AI apocalypse or something, I’m sure it’ll be more manageable, and the fix could hopefully be done on a cave wall using a flint spear tip.

Or set 0 to be the Big Bang and make the type unsigned. Do it the same time we convert all temperature readings to Kelvin.

And count Planck time instead of seconds.. it's not as impossible as it may sound. You'll need more than 128 bits but less than 256 bits even if the epoch is the Big Bang (I can't recall exactly how many bits are needed, but I did the math once, some years ago). And it'll be compatible with alien or future time systems too, in case what we call a second (currently defined by caesium-133 periods) changes.
Post reply on HN