Common Calendrical Fallacies
yourcalendricalfallacyis.com
Common Calendrical Fallacies
1–10 of 53 posts
Re: Common Calendrical Fallacies
#2Some 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.
Re: Common Calendrical Fallacies
#3This 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.
Re: Common Calendrical Fallacies
#4I like this.
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.
Re: Common Calendrical Fallacies
#5This 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 lo…
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.
Re: Common Calendrical Fallacies
#6This 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 lo…
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.
Re: Common Calendrical Fallacies
#7This 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 lo…
> 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.
Re: Common Calendrical Fallacies
#8Pretty 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.
Re: Common Calendrical Fallacies
#9Some 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 an…
> 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.
Re: Common Calendrical Fallacies
#10I 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