Some of these are quite interesting, e.g. that Oceania has an offset from ITC >12 hours. Others are coming of more like pedantic "gotcha" questions where the answer is that some more or less obscure calendar system is the exception here. Yeah sure it is, why wouldn't the year in the japanese calendar depend on the death of their emperor. That just isn't something my small software tool is likely willing to support anyways.
So I think instead of "scolding" the reader with a False here, maybe a Depends would be both more friendly and more well suited.
> So I think instead of "scolding" the reader with a False here, maybe a Depends would be both more friendly and more well suited.
I like this. False suggests it is objectively false, but you're right, it really depends on more information. And it's important that people working with dates and times understand that they need more information.
At least they need enough i formation to realize they don't wanna handle this entirely by themselves.
The point however is that every dev sometimes needs to make assumptions about an calendar — even those who are smart enough not to write their own calendar. E.g. if you think about a typical fitness tracker of course the devs will have to make assumptions about weeks and months, instead of supprting every calendar under the sun.
This is why a Depends makes a lot more sense here: Knowing that it exists is good, but you might not have to support it in an 1.0 release
Not sure if scolded is the right word (non-native speaker), but I think "False" as an answer to an rethorical question is only worth much if the point you are making after the false is one that is really obviously false.
If it is false only if you pinch hard and look from the right angle it comes of as "Oh come on, you just don't want me to get this right" — which in this case runs counter to the whole idea of the blog post as I understood it.
I had a teacher once who was like that: whenever someone he didn't like got something wrong he would pull out some pedantic detail to still make it look like the person was false, even though they really really were not. I kinda think this is just a little bit unproductive in an educational context.
This comes off as very "well akchtually"; more snarky than helpful.
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.
You say "No software project cares"... but I'm sure there are pieces of software out there used for dealing with historical/archeological data and have to deal with stuff like this :) I would not want to have to work on it.
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.
And astronomers. A lot of work goes into matching up eclipses to pin down exact dates and then reconstructing regal years. Even with this there is some uncertainty in the timeline of the Assyrian empire.
It might be a context-specific thing, but I didn't really find the tone snarky or off-putting. Those pedantic historical edge-cases are pretty interesting even though I will probably never have to worry about them.
> This comes off as very "well akchtually"; more snarky than helpful.
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.
>Months always have 30 or 31 days in them
>False. February. Duh.
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.
>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.
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?!?!
> anyone who says "the current year is 2020" is talking about the Gregorian calendar
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!
> 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.
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.
> This comes off as very "well akchtually"; more snarky than helpful.
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.
> 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.
> Obviously, anyone who says "the current year is 2020" is talking about the Gregorian calendar that everyone is familiar with
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™.
I've seen a number of "Falshoods programmers believe about X" and they almost never provide examples or explanations, which is rather frustrating for some of the more obscure or weird cases.
Pretty cool reminder that calendars and time in general are one of those troublesome domains of fractal complexity. Even this seems to just scratch the surface of regional variations of certain traditional calendars, how people's ages can be determined differently, etc.
I wish there was a version of this that only contained examples relevant to e.g. the Gregorian calendar, or even within the subset of the Gregorian calendar specified within POSIX.
I get whiplash going back and forth between "relevant thing I need to care about" and "obviously irrelevant" in this list
Back in the dark ages, my first project as a professional software engineer was working on a web app for something or other. I had to write a JS function to figure out whether the current year was a leap year. It didn't go well....
It was a painful experience but it aught me a valuable lesson. To this day I would sooner write my own bootloader than roll my own date/time library.
> So if you’re writing code and are trying to use the time 00:00:00 to represent “no time”, you will be wrong in these countries.
Well, obviously using `00:00:00` as no-time is a terrible idea, but isn't that statement just wrong? If it's used to represent no-time, it would actually have a very low chance of doing what it's supposed to do in those countries, but fail all the time at all other time zones.
FogBugz calculated “daily task” times based on the site’s time zone. If this was set to a timeline like Chile, the daily tasks processor would crash in a loop, until the next day, which did have a 00:00:00. This caused horrible alerts to plague the systems engineer on call.
How about "the sun is approximately overhead at noon", "the sun is at its highest point in the sky at noon", "the sun rises each day", "noon is approximately the time that people eat a midday meal", or "midnight is a good time to switch which day 'tomorrow' refers to".
I've made many mistakes attributable to "tomorrow" switching at midnight according to computers when in common human usage "tomorrow" really switches closer to sunrise, and certainly not before one goes to bed unless one is staying up all night.
False, the current year according to the Grogorian calendar is 2022.
Disappointing an article as pedantic as this one fails itself. (Yes, I am aware it was likely written in 2020. That is the point: it assumed the reader read it in 2020.)
He omitted a really big one - the beginning of spring. Most people are convinced spring begins at the equinox around 20th March but are also quite happy to talk about Mid-Summer's Day at the summer solstice around 20th June. Sorry, ya can't have it both ways. If the summer solstice is mid-summer then the spring equinox 3 months earlier must be mid-spring. It all boils down to how seasons are defined and here I find even astronomers can be really lazy in their thinking. Seasons are defined by the intersection of the Sun's apparent path and the equator so equinoxes are where the Sun's path crosses the equator and the solstices (Sun standing still) are the maxima and minima of the Sun's path. However, a maxima/minima can only be the mid-point of a season since points either side of a maxima/minima are equal in terms of the relative amounts of daylight. Seasons are defined by the amount of daylight, hence the summer solstice in the northern hemisphere, around 20th June, is the mid-point of summer when we celebrate "Mid-Summer's Day". All else follows from this and spring begins around 5th February in the northern hemisphere.
That's exactly the fallacy I'm referring to. Mid-Summer's day (https://en.wikipedia.org/wiki/Midsummer) is a calendrical festival observed in many cultures around 24th June close to the summer solstice. How do you define a season? What single factor determines how a season is measured? It's the relative amount of daylight. The summer solstice is the longest day.
But that's just a convention. You're not explaining the phenomenon which gives rise to seasons or even what a season is. If some other culture decided to define equinoxes and solstices as the middle of a season then that would be another valid convention so to get to the root of the matter one has to define what a season is all about. The astronomical essence of seasons is the amount of daylight relative to darkness.
I don't really care about what causes it. The exact start and end dates of the seasons don't really matter, nor do they need to be consistent. Each season has things associated with them like fall has leafs turning orange and falling, or snow in winter.
Well now you're defining seasons in terms of weather and we all know how reliable that is. Here in London we've had zero snow this winter so far so does that mean we haven't had a winter? There are plenty of countries, especially the ones close to the equator, who have never experienced snow and whose summers and winters are barely distinguishable in terms of temperature yet they still have a summer and a winter defined by the longest and shortest day of the year.
So seasons are defined by temperature? In the UK we sometimes have our coldest weather in March. Does that mean the seasons have shifted? And what about countries close to the equator - do they have permanent summer? Seasons have nothing to do with temperature. Global warming is set to make that even more apparent.
The summer solstice around 20th June will always be mid-summer in the northern hemisphere even if it's freezing cold for the 45 days before and after. It's all about daylight and darkness. Nothing else.
The entire concept of a "season" is invented. Quantizing a continuous natural phenomena into descreet bits is something humans do with everything, and we nearly never do it rigorously.
When is it "night"? At what exact moment in time does it become "night"? Nobody knows, nobody cares. It's still a useful concept.
Night is clearly defined by the Sun setting over the horizon and the following rising. The Sun's passage over the meridian is the astronomical midnight.
It’s not always clear. For instance pilots can log night hours once it’s civil twilight, but there’s also nautical twilight and then astronomical twilight, all defined by the number of degrees below the horizon the sun is. What we consider “night” is pretty arbitrary.
The sun passing the horizon is affected by your vertical position. Someone in the lobby of a skyscraper has a different sunset time than someone near the top.
This is like the problem with astrology, since there are actually 13 sidereal months. You can even see that in the charts that show the star and planet locations on any given day, but somehow they are ignored by "psychics" everywhere.
I have found NSDate/NSCalendar to be the best designed API for date and time calculations, and I never knew it was built on top of ICU. It discourages bad assumptions while many others try to make a more 'fluent' interface that encourages them.
When I first tried Joda in Java it had a builder interface that stank, I was able to easily write tests that produced the wrong date or threw an exception simply by changing the order of construction. But I think that's long gone.
52 comments
[ 2.6 ms ] story [ 111 ms ] threadSo I think instead of "scolding" the reader with a False here, maybe a Depends would be both more friendly and more well suited.
I like this. False suggests it is objectively false, but you're right, it really depends on more information. And it's important that people working with dates and times understand that they need more information.
The point however is that every dev sometimes needs to make assumptions about an calendar — even those who are smart enough not to write their own calendar. E.g. if you think about a typical fitness tracker of course the devs will have to make assumptions about weeks and months, instead of supprting every calendar under the sun.
This is why a Depends makes a lot more sense here: Knowing that it exists is good, but you might not have to support it in an 1.0 release
It's a blog post, how can a "false" make you feel scolded?
If it is false only if you pinch hard and look from the right angle it comes of as "Oh come on, you just don't want me to get this right" — which in this case runs counter to the whole idea of the blog post as I understood it.
I had a teacher once who was like that: whenever someone he didn't like got something wrong he would pull out some pedantic detail to still make it look like the person was false, even though they really really were not. I kinda think this is just a little bit unproductive in an educational context.
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.
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.
And I mean, the site is about calendrical fallacies, I expected a scolding for my preconceived notions on dates and times going in.
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.
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 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?!?!
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!
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.
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.
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...
https://en.m.wikipedia.org/wiki/Old_Style_and_New_Style_date...
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™.
I've seen a number of "Falshoods programmers believe about X" and they almost never provide examples or explanations, which is rather frustrating for some of the more obscure or weird cases.
I get whiplash going back and forth between "relevant thing I need to care about" and "obviously irrelevant" in this list
yourcalendricalfallacyis.com should have categories. General > Generic Programming > language specific
It was a painful experience but it aught me a valuable lesson. To this day I would sooner write my own bootloader than roll my own date/time library.
Well, obviously using `00:00:00` as no-time is a terrible idea, but isn't that statement just wrong? If it's used to represent no-time, it would actually have a very low chance of doing what it's supposed to do in those countries, but fail all the time at all other time zones.
I've made many mistakes attributable to "tomorrow" switching at midnight according to computers when in common human usage "tomorrow" really switches closer to sunrise, and certainly not before one goes to bed unless one is staying up all night.
False, the current year according to the Grogorian calendar is 2022.
Disappointing an article as pedantic as this one fails itself. (Yes, I am aware it was likely written in 2020. That is the point: it assumed the reader read it in 2020.)
Spring: March April May
Summer: June July August
Fall: September October Novmeber
Winter: December January February
I define it as a period of time between a equinox and a solstice.
If it didn't get colder than fall than it would be possible to skip winter.
In part. I'd say it's a combination of the temperature and amount of light you get per day.
When is it "night"? At what exact moment in time does it become "night"? Nobody knows, nobody cares. It's still a useful concept.
~ Events always start and end on the same day
~ Any event has a start and end time
~ All events are on a specific day
> The current year is 2020
> False. It’s the year 5780 in the Hebrew calendar.
Like an Easter egg.
I have found NSDate/NSCalendar to be the best designed API for date and time calculations, and I never knew it was built on top of ICU. It discourages bad assumptions while many others try to make a more 'fluent' interface that encourages them.
When I first tried Joda in Java it had a builder interface that stank, I was able to easily write tests that produced the wrong date or threw an exception simply by changing the order of construction. But I think that's long gone.