Live data from Hacker News

Falsehoods programmers believe about Unix time

alexwlchan.net

161–170 of 275 posts

Re: Falsehoods programmers believe about Unix time

#161

Earlier quoted context omitted.

The third principle of Continuous Delivery is "If something is difficult or painful, do it more often". So, if leapseconds are actually painful for you, then maybe we need to contemplate making this kind of adjustment on a finer timescale, like milliseconds. OTOH, if you think leapseconds are painful now, just you wait until you postpone this pain and do it even less frequently.

The obvious correction is to change the duration of a second such that a year is exactly $integer seconds long. While this will make the duration of second drift from year to year, that drift is so small that everyday devices like consumer-grade computers could just ignore it, provided they're NTP synced once every five years or so. Physicists can just keep using whatever they're using and call it by a different name…

The core issue is that the number of days per year is messy, so it's not possible to have a 'nice' number of seconds in a day and also in a year.

The best solution is probably just to use a nice number of seconds per day and accept the fact that in 100ish years summer will start in March, not December. It's not like we need to build our entire society around planting and harvest any more.

Re: Falsehoods programmers believe about Unix time

#162

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…

> Move any jumps in time to once a century (or millennium).

You hear a lot of people remarking that Let's Encrypt has made things better by requiring certs to be reconfigured more often rather than less. I know they're not exactly the same as time in general, but as a general idea, knowing that you need to do some fiddling often and automating it, might be better than growing complacent because nothing needs to be done for 50 years.

Might be setting things up for a lot of work when that next change comes due.

Re: Falsehoods programmers believe about Unix time

#163
post #154
post #117

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 cont…

Agree. In other words, computers should use UT1 (where one day is a rotation of the earth, and 86400 seconds; and consequently a second is not a SI second).

Correct, time_t second is already in practice not an "SI second" the later being defined by the "counts" in the "atomic" clocks:

"the duration of 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 atom" (at a temperature of 0 K)" https://en.wikipedia.org/wiki/Second

That SI second is what I refer to when I mention an "atomic clock second."

The time_t second is effectively simply one 86400th of a day.

Re: Falsehoods programmers believe about Unix time

#164
> If I wait exactly one second, Unix time advances by exactly one second, unless a leap second has been removed.

What complete and utter bogus. Just because some moron in the IERS has defined that my day has more or less seconds doesn't mean time stands still for me. If I wait 1 second in UNIX time, one second passes. As in: If I am travelling at 1 meter per second, and I wait one second in UNIX time, I travelled one meter. Maybe UTC didn't advance but time in the real, actual world advanced.

The ground truth is UNIX time which advances monotonically and linearly. UTC is a political garbage mess plopped on top of actual time. So, on the graph you've got it the wrong way around: The x-axis should be UNIX time, the y-axis should be UTC time.

Re: Falsehoods programmers believe about Unix time

#166
post #161

Earlier quoted context omitted.

The obvious correction is to change the duration of a second such that a year is exactly $integer seconds long. While this will make the duration of second drift from year to year, that drift is so small that everyday devices like consumer-grade computers could just ignore it, provided they're NTP synced once every five years or so. Physicists can just keep using whatever they're using and call it by a different name…

The core issue is that the number of days per year is messy, so it's not possible to have a 'nice' number of seconds in a day and also in a year. The best solution is probably just to use a nice number of seconds per day and accept the fact that in 100ish years summer will start in March, not December. It's not like we need to build our entire society around planting and harvest any more.

That's not anywhere close to "the best solution"

Re: Falsehoods programmers believe about Unix time

#167

So, if I adopt smearing for my NTP, everything works fine.

Except then, a second isn't actually a second.

But it pretty much is.

Einstein showed us seconds aren't seconds anyway, unless you happened to have the same inertial frame.

Re: Falsehoods programmers believe about Unix time

#169
post #67
post #48

Earlier quoted context omitted.

Are you saying Unix time doesn't get adjusted when there are calendar changes in the box?

Correct. When was the last time you changed UNIX time due to summer time/daylight savings?

It follows UTC, so that doesn't apply. From what I understand, it does follow things like leap seconds, though.

Re: Falsehoods programmers believe about Unix time

#170
post #77

Earlier quoted context omitted.

> A day is defined as the rotation of the earth around its axis. When you get into the world of programming for most people, businesses especially, a day is defined as 24 hours. We like to think that our days and months and years are tied to vast astronomical forces, for romantic reasons, but when it comes down to it, everything comes back to the second, and the second is defined to be a single unvarying length of ti…

Well, just to nitpick, seconds do vary in comparative length from reference frame to reference frame...and that actually does start to matter in global computing.

Seconds don't vary, your approximation of a second varies.

If you want to nitpick, you're going to need to start with Cesium-133 oscillation periods as averaged from over nine billion samples.

Post reply on HN