This comes off as very "well akchtually"; more snarky than helpful.<p>A great example:<p>>It is normal that the Sept-, Oct-, Nov-, and Dec- months are numbered 9, 10, 11, and 12<p>>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.<p>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.<p>> The current year is 2020<p>> False. It’s the year 5780 in the Hebrew calendar.<p>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.<p>That said, I will never willingly write code that deals with times / calendars.
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.<p>So I think instead of "scolding" the reader with a <i>False</i> here, maybe a <i>Depends</i> would be both more friendly and more well suited.
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.<p>I get whiplash going back and forth between "relevant thing I need to care about" and "obviously irrelevant" in this list
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".<p>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.
> 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.<p>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.
> The current year is 2020<p>False, the current year according to the Grogorian calendar is 2022.<p>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.)
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....<p>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.
I like this.<p>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.
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.
I was relieved to read the final paragraph.<p>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.<p>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.
I like this JavaDoc <a href="https://docs.oracle.com/javase/8/docs/api/java/time/chrono/ChronoLocalDate.html" rel="nofollow">https://docs.oracle.com/javase/8/docs/api/java/time/chrono/C...</a>
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.
This is like the problem with astrology, since there are actually 13 sidereal months. You can even <i>see</i> that in the charts that show the star and planet locations on any given day, but somehow they are ignored by "psychics" everywhere.