Live data from Hacker News

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

benjoffe.com

71–80 of 100 posts

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

#71

Earlier quoted context omitted.

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.

Ah, you're right. I saw that the expression in the comment and in the code was the same and assumed that the commented bit was valid C++ code. You got me to look again and it's obvious that that isn't the case. I had even gone looking through the codebase to see if std::floor was included, and still missed the incorrect `^`.

I guess in that case as long as the 128-bit type supports constexpr basic math operations that should suffice to replace the hardcoded constants with their source expressions.

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

#72
post #49

Earlier quoted context omitted.

And (oct)ober was the 8th month of the year, (nov)ember the ninth, (dec)ember the tenth!

Weird parenthesization. The latin numbers are septem, octo, novem, decem for 7, 8, 9, 10. And then they all have a -ber suffix.

The three letter prefixes show up in English (eg oct in octal, dec in decimal, etc.).

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

#73

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?

Druid tells you

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

#74
post #65

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.

Could you elaborate on what you mean? I think it's already impossible to accurately turn a future timestamp into a local time, leap seconds or not, because of timezone shenanigans. So I'm probably misunderstanding what you're talking about.

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

#75
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.

What were they before? Quintember? Sextober?

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

#76
post #75

Earlier quoted context omitted.

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.

What were they before? Quintember? Sextober?

Basically, yes. Quintilis and Sextilis.

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

#77
post #67

Earlier quoted context omitted.

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

Equinox or something like that?

The precise equinox sounds fussy to measure and even then you need to know three weeks before the equinox. While counting days is very easy.

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

#78
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…

I don't know if it ever made it to production, and I don't remember exactly why it made sense at the time, but one early hack I did was passing a date in Julian format because there weren't enough bits to pass a full timestamp.

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

#79
post #9

Nice to see that there are still some jewels left to be dug out from the algorithm land.

Well searching for strings, appending strings, comparing strings. All still unimplemented in standard libs. (Strings being unicode of course)

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

#80
post #25
post #7

I wrote my own date calculation functions a while ago. And during that, I had an aha moment to treat March 1 as the beginning of the year during internal calculations[0]. I thought it was a stroke of genius. It turns out this article says that’s the traditional way. [0]: https://github.com/kccqzy/smartcal/blob/9cfddf7e85c2c65aa6de...

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

> not completely coincidentally, March was also the first month of the year in many historical calendars.

And often the last month too. The early modern English calendar began the year on March 25.

This is coincidental in relation to the offset in the names of the months. The Romans started their year in January just like we do today.

(Though in a very broad sense, it's common to begin the year with the new spring. That's the timing of Chinese new year and Persian new year. I believe I've read that the Roman shift two months backward was an administrative reform so that the consuls for the year would have time to prepare for the year's upcoming military campaigns before it was time to march off to war.)

Post reply on HN