Falsehoods There are always 24 hours in a day. February is always 28 days long. Months have either 28, 29, 30, or 31 days. The day before Saturday is always Friday. GMT and UTC are the same...
Falsehoods
There are always 24 hours in a day.
February is always 28 days long.
Months have either 28, 29, 30, or 31 days.
The day before Saturday is always Friday.
GMT and UTC are the same timezone.
Any 24-hour period will always begin and end in the same day (or week, or month).
The difference between two timestamps is an accurate measure of the time that elapsed between them.
Daylight saving time always adjusts by an hour.
Time always goes forwards.
Some of these are obvious, others I'm curious when they would not be true (when does a month not have 28-31 days? 45 BC in the Julian calendar?).
From the longer list, my favorite is: Stealth fighters hit by software crash
From the longer list, my favorite is:
Contiguous timezones are no more than an hour apart. (aka we don’t need to test what happens to the avionics when you fly over the International Date Line)
Probably something to do with date arithmetic? For example, daylight saving time in Cuba begins at midnight on March 11th of this year, so: import DateTime from "my-date-library"; let date =...
importDateTimefrom"my-date-library";letdate=DateTime.date("2024-03-12",{timestamp:"00:00",locale:"cuba/CU"})/;// midnight the day after DSTdate.subtract({hours:24});print(date.format("yyyy-MM-dd"));// "2024-3-10"print(date.format("yyyy-MM-dd, hh:mm"));// "2024-3-10, 23:00"
We've just subtracted 24 hours, or 1 day. But we went back 2 days, because there were only 23 hours on March 11, not 24. Thus, "32 days" in March.
I haven't really thought about the semantics of writing a date library too much until now, but my guess is the right approach is to always calculate dates in absolute units from the beginning of time*", separately keep tabs on when DST is supposed to start in a given locale, and calculate the appropriate date representation based on whether or not it's DST.
I got the year wrong by 1 but 46 BC did have differemt length months in preparation for the introduction of the Julian calendar. That doesn't affect 46 BC in the Gregorian calendar, though.
I got the year wrong by 1 but 46 BC did have differemt length months in preparation for the introduction of the Julian calendar. That doesn't affect 46 BC in the Gregorian calendar, though.
Julius Caesar added Mercedonius (23 days) and two other intercalary months (33 and 34 days respectively) to the 355-day lunar year, to recalibrate the calendar in preparation for his calendar reform, which went into effect in 45 BC.[1][2][3] This year therefore had 445 days, and was nicknamed the annus confusionis ("year of confusion") and serves as the longest recorded calendar year in human history.[4] The actual planetary orbit-year remained the same.
Dates are so hard. Time zones are even worse. Date libraries sometimes mess it up. I never want to be involved in writing one. It's one of those non obvious things that look straightforward but...
Dates are so hard. Time zones are even worse. Date libraries sometimes mess it up. I never want to be involved in writing one.
It's one of those non obvious things that look straightforward but are incredibly complicated. I still say we should all go on UTC.
Falsehoods
Some of these are obvious, others I'm curious when they would not be true (when does a month not have 28-31 days? 45 BC in the Julian calendar?).
From the longer list, my favorite is:
Stealth fighters hit by software crash
Someone has never had to coordinate a multi time zone meeting with IST.
Probably something to do with date arithmetic? For example, daylight saving time in Cuba begins at midnight on March 11th of this year, so:
We've just subtracted 24 hours, or 1 day. But we went back 2 days, because there were only 23 hours on March 11, not 24. Thus, "32 days" in March.
I haven't really thought about the semantics of writing a date library too much until now, but my guess is the right approach is to always calculate dates in absolute units from the beginning of time*", separately keep tabs on when DST is supposed to start in a given locale, and calculate the appropriate date representation based on whether or not it's DST.
I got the year wrong by 1 but 46 BC did have differemt length months in preparation for the introduction of the Julian calendar. That doesn't affect 46 BC in the Gregorian calendar, though.
I wonder if it's related to leap seconds. December 31 could end up longer than a day if you're counting in seconds or smaller increments.
Dates are so hard. Time zones are even worse. Date libraries sometimes mess it up. I never want to be involved in writing one.
It's one of those non obvious things that look straightforward but are incredibly complicated. I still say we should all go on UTC.
Related old video from Computerphile, featuring Tom Scott:
The Problem with Time & Timezones