3 ms·

Adoption of the Gregorian calendar [1] resulted in a number of short months in a bunch of countries. Different but related, 46 BC, the year of adoption of the

Adoption of the Gregorian calendar [1] resulted in a number of short months in a bunch of countries. Different but related, 46 BC, the year of adoption of the Julian calendar, had 15 months [2]. [1]: https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_calendar https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale... [2]: https://www.uh.edu/engines/epi2364.htm https://www.uh.edu/engines/epi2364.htm

astrobe_ 4y ago
That's what I thought. This list mixes "falsehoods" that nobody with a bit of common sense - even children - would believe, and pedantry that could be useful to 0.001% of developers. For most programs, Time starts in 1970. IMO, this list is only good at... wasting time. Except for the multiple statements (that could be one or two) that point out that there's not such a thing like "identical clocks" and "same time on two clocks".
- wink 4y ago
  So "most" programs can ignore birth dates of people older than 52? I don't think so.
  - trentgreene 4y ago
    Do most programs need to know the birth date of the user?
    - thfuran 4y ago
      Most of the programs I write do. Well, of people, but not typically the user.
  - astrobe_ 4y ago
    Most programs don't deal with birth dates and people. It's like stating that most "computers" are neither on a desktop nor in a pocket. Technically correct, as counter-intuitive as it is.
jwie 4y ago
I suppose it depends on if you think about a “fact month”, that is the series of days people experience, or the formal calendar months as the things being handled by the system. The daylight savings time transition doesn’t “shorten” or “lengthen” the day, it merely transforms the clock. The day isn’t 25 hours or 23 hours. This is essentially the same thing as the Julian/Gregorian swap. The day didn’t really change, just the system we use to understand what day it is. The span of time users experienced was weird, but this wasn’t the unit of time being shorter or longer. It’s an artifact of the transition not anything happening to the time. A lot of these falsehoods on the list can be side stepped by distinguishing between the dimensions and the facts about representing time.

astrobe_ 4y ago

That's what I thought. This list mixes "falsehoods" that nobody with a bit of common sense - even children - would believe, and pedantry that could be useful to 0.001% of developers. For most programs, Time starts in 1970. IMO, this list is only good at... wasting time. Except for the multiple statements (that could be one or two) that point out that there's not such a thing like "identical clocks" and "same time on two clocks".

wink 4y ago
So "most" programs can ignore birth dates of people older than 52? I don't think so.
- trentgreene 4y ago
  Do most programs need to know the birth date of the user?
  - thfuran 4y ago
    Most of the programs I write do. Well, of people, but not typically the user.
- astrobe_ 4y ago
  Most programs don't deal with birth dates and people. It's like stating that most "computers" are neither on a desktop nor in a pocket. Technically correct, as counter-intuitive as it is.

jwie 4y ago

I suppose it depends on if you think about a “fact month”, that is the series of days people experience, or the formal calendar months as the things being handled by the system. The daylight savings time transition doesn’t “shorten” or “lengthen” the day, it merely transforms the clock. The day isn’t 25 hours or 23 hours. This is essentially the same thing as the Julian/Gregorian swap. The day didn’t really change, just the system we use to understand what day it is. The span of time users experienced was weird, but this wasn’t the unit of time being shorter or longer. It’s an artifact of the transition not anything happening to the time. A lot of these falsehoods on the list can be side stepped by distinguishing between the dimensions and the facts about representing time.