4 ms·
> or my favorite January 1, 1600 since 1600 is a multiple of 400 You need to deal with 1600 and 2000 being leap year. While 1700, 1800, 1900 not being a leap
by habibur 1y ago
> or my favorite January 1, 1600 since 1600 is a multiple of 400
You need to deal with 1600 and 2000 being leap year.
While 1700, 1800, 1900 not being a leap year.
I limit dates from 1900 to 2100. All !year%4 = leap year.
Especially when you try to convert int_date to y,m,d things get tricky.
- jerf 1y ago"Years are not leap years, unless % 4, unless % 100, unless % 400." It's a wacky rule for sure. 2000 was fun. Everyone knows about "unless % 4", but there was also an interesting and very vocal set of people who knew about the "unless % 100" but somehow knew that without knowing about the "unless % 400" part. A very specific level of knowledge.
- kccqzy 1y agoThat's exactly why I propose a multiple of 400, not a multiple of 100. The proleptic Gregorian cycle is a 400-year cycle. There are 97 leap years in it. What's tricky about it? Just take a look at my code: https://github.com/kccqzy/smartcal/blob/9cfddf7e85c2c65aa6dec1ac183a73a58379e8f8/src/smartcal/core.cljs#L55 https://github.com/kccqzy/smartcal/blob/9cfddf7e85c2c65aa6de...
- oneshtein 1y agoWhy not just make a map of dates to days since 0001-01-01 in a plain text, then compress it at build time? We are not constrained by memory anymore. Just use simple database as source of truth with all days passed since a start of human history (e.g. 6000 years ago) with labels such as "this day 12345678 was known as day XXXX-xx-xx in those regions, also known as YYYY-yy-yy in those regions, also known as ZZZZZ in this specific region". It's not a hard task to automatically compress such database into a compact representation.