5 ms·

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,

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.

noneeeed 5y ago
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.
- wbl 5y ago
  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.
allemagne 5y ago
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.
- GenZRiseUp 5y ago
  I found them snarky as well, but interesting enough that I read it through for any help on trivia nights. And I mean, the site is about calendrical fallacies, I expected a scolding for my preconceived notions on dates and times going in.
nulbyte 5y ago
> 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.
contravariant 5y ago
It would sound decidedly less snarky if they didn't start all sentences with "False.", but listing pathological examples is not by itself snarky.
- BitwiseFool 5y ago
  >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.
BitwiseFool 5y ago
>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?!?!
yorwba 5y ago
> 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!
blahedo 5y ago
> 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.
II2II 5y ago
> 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.
throw0101a 5y ago
> 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. Unless you're doing astronomy: * https://stellarium.org/doc/0.21/classJulianCalendar.html https://stellarium.org/doc/0.21/classJulianCalendar.html * https://en.wikipedia.org/wiki/Julian_year_(astronomy) https://en.wikipedia.org/wiki/Julian_year_(astronomy) * https://en.wikipedia.org/wiki/Julian_day https://en.wikipedia.org/wiki/Julian_day * https://squarewidget.com/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-dates-functions-0c7fa6aa-daff-402e-9990-93a5b76ba018 https://support.microsoft.com/en-us/office/insert-julian-dat...
tdeck 5y ago
While we're at it, I'm surprised there's no mention that the new year started in March for English speakers into the late 18th century: https://en.m.wikipedia.org/wiki/Old_Style_and_New_Style_dates https://en.m.wikipedia.org/wiki/Old_Style_and_New_Style_date...
berkes 5y ago
> 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™.

noneeeed 5y ago

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.

wbl 5y ago
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.

allemagne 5y ago

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.

GenZRiseUp 5y ago
I found them snarky as well, but interesting enough that I read it through for any help on trivia nights. And I mean, the site is about calendrical fallacies, I expected a scolding for my preconceived notions on dates and times going in.

nulbyte 5y ago

> 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.

contravariant 5y ago

It would sound decidedly less snarky if they didn't start all sentences with "False.", but listing pathological examples is not by itself snarky.

BitwiseFool 5y ago
>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.

BitwiseFool 5y ago

>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?!?!

yorwba 5y ago

> 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!

blahedo 5y ago

> 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.

II2II 5y ago

> 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.

throw0101a 5y ago

> 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. Unless you're doing astronomy: * https://stellarium.org/doc/0.21/classJulianCalendar.html https://stellarium.org/doc/0.21/classJulianCalendar.html * https://en.wikipedia.org/wiki/Julian_year_(astronomy) https://en.wikipedia.org/wiki/Julian_year_(astronomy) * https://en.wikipedia.org/wiki/Julian_day https://en.wikipedia.org/wiki/Julian_day * https://squarewidget.com/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-dates-functions-0c7fa6aa-daff-402e-9990-93a5b76ba018 https://support.microsoft.com/en-us/office/insert-julian-dat...

tdeck 5y ago

While we're at it, I'm surprised there's no mention that the new year started in March for English speakers into the late 18th century: https://en.m.wikipedia.org/wiki/Old_Style_and_New_Style_dates https://en.m.wikipedia.org/wiki/Old_Style_and_New_Style_date...

berkes 5y ago

> 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™.