Context always matters.
Which is why we have (or should have) Domain Boundaries. Within which we have (or should have) ubiquitous language. And within wich our deliberate assumptions always hold true.
More practical, this is one reason why you want to isolate dependencies behind an anti-corruption layer, or some adapters or whatever architecture to isolate. It isolates your internal context, where it is fine to assume 2020 is western calendar and not the Thai calendar (where the current year is 2565, and used by some hundred million potential customers). Eventhough the library you use may deal with all those intricacies, within your domain, you deliberately don't.
These problems are solved. Eric Evans wrote a fantastic book (DDD) explaining how it has been solved, 18 years ago. We must keep bringing such problems up. But we should try to avoid inventing solutions again and again.
And we should certainly avoid giving up, and saying this silly, unsolvable or Just Too Hard™.
Maybe. Maybe they're using a different calendar where the current year is actually 2020. The current year is 2565 in the Thai calendar. Putting "๒๕๖๕ กิโล, 2565 กิโล" into Google Translate to translate Thai into English results in "2022 kilometers, 2022 kilometers", because it treats the numbers as years and tries to helpfully convert them to Gregorian. Fun!
And I mean, the site is about calendrical fallacies, I expected a scolding for my preconceived notions on dates and times going in.
Agreed. It would have been much more useful if the article was upfront about its intent, rather than stating it in the last paragraph along with categorizing the potential pitfalls in writing such code (e.g. time, international, cultural, historic, etc.).
The categorizing is important since most, if not all, of the cases will be relevant in some circumstances and not in others. A day planner may need to consider international variation, you may need to consider leap seconds in log files, while historic and cultural variations is useful for some planetarium software.
I agree in that I don't like the snark but this one fact bugs me more than people can possibly empathize with. Once I realized October should be the eighth month, switch was permanently flipped in my brain and now I type 8 for October and it trips me up constantly.
Look, I get that calendar reform isn't easy. But the old months were all clearly named after numerical sequences. Why would the Romans intentionally break the numbering?!?!
I take your main point, but its relevance is at least somewhat more recent than the Roman Empire: I've seen engraved statuary that's only a few hundred years old, in France, that used abbreviations like "VIIbre" for "septembre". Still not of direct interest to a software project probably but in recent enough history that you might interact with it in scanned archive data.
Archeologists must spend a lot of time reconciling different calendars and all the changes that have happened over the years.
And yeah, if I go the rest of my career never having to work with calendars or scheduling I'll be a happy man.
Unless you're doing astronomy:
* https://stellarium.org/doc/0.21/classJulianCalendar.html
* https://en.wikipedia.org/wiki/Julian_year_(astronomy)
* https://en.wikipedia.org/wiki/Julian_day
* https://squarewidget.com/julian-day/
> There is also a Julian date commonly used in astronomy, which is a serial date system starting on January 1, 4713 B.C.E.
* https://support.microsoft.com/en-us/office/insert-julian-dat...
This one in particular rubbed me the wrong way. But if it were rewritten as something like
"Don't forget about February, which is normally 28 days, unless it is a leap year in which it case it is 29 days long. But did you know that if the year is divisible by 100, we skip the leap day? Unless the year is also divisible by 400, in which case, we DO include the leap day. So even the exception has exceptions."
Or something like that. Adds a little more detail on top of what is fairly obvious.
I don't think so, but even if it does, I know some folks that could read this. Plenty of folks I work with build reports that modify times in ways that are incomprehensible. Even the Olympics can't get their online schedule right: Change to "my time," and the times may be right, but most of the days are still wrong for me.
https://en.m.wikipedia.org/wiki/Old_Style_and_New_Style_date...
A great example:
>It is normal that the Sept-, Oct-, Nov-, and Dec- months are numbered 9, 10, 11, and 12
>False. This is very weird. They used to be months 7, 8, 9, and 10, but some reform to the Roman calendar back in the day resulted in the creation of January and February, which messed everything up.
No software project cares what the calendar looked like during the roman empire. Sure, its quirky that OCTober is month 10 instead of 8. Doesn't affect anything at all.
> The current year is 2020
> False. It’s the year 5780 in the Hebrew calendar.
Obviously, anyone who says "the current year is 2020" is talking about the Gregorian calendar that everyone is familiar with. If your wife asked to have dinner at 7pm, are you going to scold her for not specifying the implied UTC offset? Its silly to even bring up.
That said, I will never willingly write code that deals with times / calendars.