Falsehoods programmers believe about Unix time

Leap smearing makes #3 no longer false, but #1 and #2 remain false

I read articles like this and come to the conclusion that UTC is flawed, not Unix time. Leap seconds seem mostly useless. People seem to think they are important for astronomy, but for every astronomical calculation I have ever done, your first step is converting from UTC to TAI. Move any jumps in time to once a century (or millennium). Such jumps have occurred in the past (Julian to Gregorian) and are easy to handle programmatically. People think time increases monotonically and it's confusing to push it any other way.

The idea that I don't know how many UTC seconds will pass between now and May 15, 2022 0:00:00 is absurd. The fact that a clock sometimes reads 23:59:60 is also absurd, as is the "possibility" of a 23:59:59 being a forbidden time on a certain date if we ever add a leap second of the opposite sign.

I disagree about obvious. Some are not, IMO, obvious, and some are actually true within reasonable bounds.

From one of the previous lists[2]:

> DST is always an advancement by 1 hour

I'd point to this one as not "obvious": it is false. Some extreme northern/southern locations (where the seasonal day lengths get really long/short, since you're so close to the pole) adjust by 2 hours. (E.g., the aptly named Antarctica/Troll[4].)

> Months have either 28, 29, 30, or 31 days.

> The day of the month always advances contiguously from N to either N+1 or 1, with no discontinuities.

I usually presume that I'm either a. working in the proleptic Gregorian calendar, b. I am working within a range of time (e.g., company start to foreseeable future) in which the Gregorian calendar is a safe assumption or c. I am working in a situation where I know I'm not working with the Gregorian calendar (e.g., the app/job has specific requirements around, say, a lunar calendar) and I'll know I'm in one of those exceptional case when they apply / the falsehood won't be believed to be false.

Within that assumption, that "falsehood" isn't false. It's true: there is no month within the Gregorian calendar that does not have 28, 29, 30, or 31 days.

The trouble is the transition onto the calendar. Some languages — in particular, some parts of Java[3] do this — choose a date at which the calendar was adopted and actually expose that in their routines. (But note, however, that the Gregorian calendar was not adopted overnight; it started in 1582 and continued until 1923!)

For example, when Great Britain[1] adopted it:

> Through enactment of the Calendar (New Style) Act 1750, Great Britain and its colonies (including parts of what is now the United States) adopted the Gregorian calendar in 1752, by which time it was necessary to correct by 11 days. Wednesday, 2 September 1752, was followed by Thursday, 14 September 1752.

Again using Java as an example, I believe it chooses the Spanish transition (1582), and since there's a jump there, too, it jumps 11 days, resulting in a very short October, making the two falsehoods listed above actually falsehoods.

But just work in the proleptic calendar. IMO, what calendar you're using is effectively part of the datetime type. Having a datetime type that uses multiple calendaring systems is like having a text/string type that also lets you put random bytes in the middle of the string.

Of course, the next falsehood was,

> There is only one calendar system in use at one time.

…which is our stated assumption of "within the Gregorian calendar". So, by definition, this is true!

There were a few others, e.g.,

> Non leap years will never contain a leap day.

That are just more fallout.

Assumptions need to be stated, and explanations would be more enlightening to the surprised reader.

[1]: https://en.wikipedia.org/wiki/Adoption_of_the_Gregorian_cale...

[2]: http://infiniteundo.com/post/25509354022/more-falsehoods-pro...

[3]: https://docs.oracle.com/javase/7/docs/api/java/util/Gregoria...

[4]: https://en.wikipedia.org/wiki/List_of_tz_database_time_zones

I don't understand this one:

> If I wait exactly one second, Unix time advances by exactly one second

How does UTC jumping around affect this? If a leap second is removed it doesn't mean you've waited 0 seconds.

I feel like this is wrong too:

> If there’s a leap second in a day, Unix time either repeats or omits a second as appropriate to make them match.

It's not Unix time doing that. It's UTC.

A reality that most of these types of blog dont mention is that you may well not have any applicable data. E.g. users registered before 2000. Or any dates at all that care about second precision.

Humans are also "wrong" but happy with that, celebrating birthdays indepenent of timezones. Some celebrate birthdays independente of the actual date birth occured like the Queen or Jesus or anyone born on the 29th of feb.

Far more likely your clock goes backwards because you fuck up your ntp config than any other reason.