Falsehoods programmers believe about Unix time

I know it will never happen because of cultural reasons, but really, we need to separate the time (as in how I describe a point on the time scale, for, let say, a meeting, especially one that involves people in globally distributed locations), and the cultural aspect (at what time people are sleeping or eating lunch).

Right now those two things are intertwined, and that's bad. Not everyone eats lunch around noon or go to bed at 23:00 anyway, so the cultural part is very fuzzy.

I should be able to describe time in an almost metric way. A unit that is the same no matter where I am in the world and doesn't change based on how fast a rock moves around a fireball. "Hey person in Japan, let's have a video meeting at 1,234,99" where that number means the same thing to the as it does to me. Its going to be dark for one of us and bright for another.

Then we can have a different unit, let's call it "day offset". That is the offset from the first number that dictates when a particular area considers to be "the day", when the average people wakes up, have lunch, have dinner, go to bed.

"Let's meet at 1,234,99. I know you're in Japan and your offset is +9,23 while here it's "-5,78" so it's a bit inconvenient, but hopefully you can make it!"

Yes, I realize I'm roughly describing how time and timezone works, with an important difference: with the current system, people live around the adjusted number. The number after the timezone is applied. After the leap seconds and all that crap is applied. Some people argue about daylight saving or no. Computers have to deal with all of it. Let's make the non-adjusted number what people use day to day, and the "offset" is a static number picked by the locals, that include stuff like daylight saving, leap seconds, and various other cultural adjustment. Its only purpose is to communicate the cultural or location difference between 2 people.

Obviously that will never happen, but Ill keep dreaming.

I've argued this and the issue comes when you try to Target another timezone from your own.

So for example if you're in EST(-5) and need to Target CST(+8) you can't give the Unix time for the other timezone because that value is relative to yours talking about another timezone.

Another falsehood, altough it goes against the POSIX standard: the epoch is midnight in UTC. There is at least one obscure Unix-like OS (can't remember the name) where the epoch is 1970-01-01 in local timezone

The article is wrong or misleading.

POSIX (and ISO) time_t is not supposed to "see" the additional leap second at all. POSIX time_t is defined to effectively always have exactly 86400 seconds per day, and no fractional parts. The seconds as defined by POSIX then can't last exactly as long as the atomic seconds. Even on the days where a leap second occur.

Wikipedia article confirms:

"Every day is treated as if it contains exactly 86400 seconds"

But that the seconds don't last the same and therefore aren't "the same" like the "atom clock" seconds should not matter for the normal users.

The graphs in the article with the fractions of the second going backwards are just poor implementations in some specific operating systems, libraries or programs. It's not something that POSIX standard prescribes that is supposed to happen.

The confusion of the common programmers, like the writer of the article or those who implemented the "backwards" behavior comes from them not understanding what they work with. Most of the users of most of the computers don't have atomic clock. So they also can't count atomic clock seconds. What the "normal" computers have are clocks which are much less precise. It's exactly for that kind of use the time_t is designed by POSIX to have exactly 86400 seconds per day -- the absolute error is at most one "atomic" second per c.a. half a year, but the error of all of the clocks directly available to the normal users in their normal computers is bigger.

So "normal" programs which do common human-related scheduling should not even try to care about the leap second. Use something like a "smeared" time as a reference:

https://developers.google.com/time/smear

The SI seconds in that article are the "real atomic clock seconds" -- but caring about them isn't even needed for normal human related computing tasks. If you have a real atomic clock, by all means synchronize it with other atomic clocks. If you have a normal computer, use the smeared time. There will be no "jumps" at all then.

Leave the leap second to the astronomers and others who are doing the "hard" time tasks, they have to care, and they have their own software for that.

I think it's a common misunderstanding worth bringing up here that probably affects more people than the falsehoods listed in the article. On roughly 3 out of the 4 times I've had a coworker run into a timezone issue (different person each time), their first impulse was to do something like what I described. (I stopped them early most of the times, so maybe they would have figured out it was the wrong way to go about it.)

Unix times show up in a lot of APIs and aren't always explicitly called "Unix times". People just see that at some point there's an integer value representing a timestamp, and the time string displayed to the user is some number of hours off, so they think they need to change that integer.