Live data from Hacker News

Falsehoods programmers believe about Unix time

alexwlchan.net

211–220 of 275 posts

Re: Falsehoods programmers believe about Unix time

#211

Earlier quoted context omitted.

500 years from now, if we're still alive, enough of us will be living in space colonies rather than on the Earth's surface that the Earth's rotation will not necessarily be immediately relevant to everyone's lives. Regardless, we've had maybe half a minute of drift since the 1970's. If the drift is 1 minute in the 2000's, 1 second per year in the 2100's, 2 seconds per year in the 2200's, 3 seconds per year in the 230…

We need a pseudo day still due to our sleeping rhythms but perhaps people could choose that based on personal preference not just stick with 24h

The day would shift half an hour in the next 600 years. That’s half as much as it shifts twice a year for DST, except it would happen gradually over a period of time roughly equal to the time between the fall of the Eastern Roman Empire and today.

Re: Falsehoods programmers believe about Unix time

#212
post #171

Earlier quoted context omitted.

This discussion isn't going to be very meaningful unless you wanna tell us what 'best' means to you.

That's fair. I simply can't see the best solution relying on getting rid of deeply ingrained culutural norms that span thousands of years.

Yeah, I can see that being an issue, at least until a decent proportion of humanity lives off-world. I can't see people living in the asteroid belts adding arbitrary leap-seconds.

Of course, once you start dealing with astronomical distances and speeds, the whole concept of a single universal measure of time kind of goes out the window anyway so it's probably going to get worse, not better. :P

(FWIW my definition of 'best' here is something along the lines of 'simple, no special rules or tinkering, gets translated to a human-readable local time on demand'. Which is pretty much how Unix epoch works, come to think of it.)

Re: Falsehoods programmers believe about Unix time

#213
post #158

Earlier quoted context omitted.

Even if there was a leap second every year... does it matter? It would still take several hundred years for the difference to be noticeable, at which point you can just change UTC by +-1h.

What it means is that the discrepancy between clocks and time of day is growing quadratically. It won't matter to us in our lifetimes. But eventually it will be a problem. It will take on the order of a thousand years for the discrepancy to add up to an hour. In 5000 years, it will be around a day. The fact that it is currently growing about a minute per century is true, but not a good predictor of what will happen.…

In 5000 years the majority of humanity, assuming we haven’t gone extinct, will live in space and the astronomy will be moot anyway.

Re: Falsehoods programmers believe about Unix time

#215

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…

Some people think one year is one orbit around the sun, and not exactly 365 days. Leap years help to keep that reality. Some people think that a day is one revolution of Earth's axis, and not exactly 86400 seconds. Leap seconds help to keep that reality. The fact that axial rotation is less predictable than orbital paths is a quirk of nature.

> Some people think that a day is one revolution of Earth's axis, and not exactly 86400 seconds

One day is more than one revolution of the planet. The sidereal day is exactly one rotation of the planet, but that's about four minutes shorter than a civil day.

The reason is that the planet also moves around the sun, so in order to get the sun to the same position in the sky for noon the planet needs to turn a little bit more than 360 degrees, about 360/365 extra.

Re: Falsehoods programmers believe about Unix time

#216

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.

> 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. That is what a lot of organizations do, "smearing" the leap second since they know their systems can't handle the discontinuity. I think this shows that software has failed in general at handling leap seconds correctly. As another said, I think leap seconds are u…

On the contrary, I think that the smearing behavior is an indication that leap seconds poison an otherwise-useful model of reality. The discontinuity is an annoying edge case driven by the fact that "time error" accumulates, so it seems to me that that a 1-day smear is a more natural approximation than an instantaneous discontinuity. That, and tuned for the attention span of human organizations.

Re: Falsehoods programmers believe about Unix time

#217
post #212

Earlier quoted context omitted.

That's fair. I simply can't see the best solution relying on getting rid of deeply ingrained culutural norms that span thousands of years.

Yeah, I can see that being an issue, at least until a decent proportion of humanity lives off-world. I can't see people living in the asteroid belts adding arbitrary leap-seconds. Of course, once you start dealing with astronomical distances and speeds, the whole concept of a single universal measure of time kind of goes out the window anyway so it's probably going to get worse, not better. :P (FWIW my definition of…

Yes... let's let future asteroid dwellers solve their own problems, which will be as much cultural as technical. Today's elegant universal solution is sometimes tomorrow's Esperanto: perfectly useless.

Re: Falsehoods programmers believe about Unix time

#218

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…

Well, the problem with this is that every simplistic view at time is... well... too simple. It's not that many people haven't tried, I especially like this article: https://qntm.org/abolish That being said, why your approach doesn't work is that there are several hard astronomical or cultural definitions that you'd throw off by playing with time. A day is defined as the rotation of the earth around its axis. A week i…

We should abolish local time too. There should be a single time for every country which is the number of milliseconds since either the beginning of human civilization, the beginning of earth or the universe.

Re: Falsehoods programmers believe about Unix time

#219

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)

Instead of building it into all into the protocol and time libraries, it's so far into the future that "We don't have to worry about that". We've had that issue before with Y2K.

> Such jumps have occurred in the past (Julian to Gregorian)

In a very different time. Today it would not be as easy - in fact since time and date are ubiquitous, it's not a simple task at all.

> The idea that I don't know how many UTC seconds will pass between now and May 15, 2022 0:00:00 is absurd.

If it matters for your use case, the don't use UTC time?

Re: Falsehoods programmers believe about Unix time

#220

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

It's almost as if we've tried something like that in the past, and the effort to avoid the worst issues was a monumental effort.
Post reply on HN