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
Falsehoods programmers believe about Unix time
211–220 of 275 posts
Re: Falsehoods programmers believe about Unix time
#212Earlier 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.
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
#213Earlier 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.…
Re: Falsehoods programmers believe about Unix time
#214Re: Falsehoods programmers believe about Unix time
#215I 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.
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
#216Earlier 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…
Re: Falsehoods programmers believe about Unix time
#217Earlier 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…
Re: Falsehoods programmers believe about Unix time
#218I 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…
Re: Falsehoods programmers believe about Unix time
#219I 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…
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
#220I 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…