121–130 of 159 posts
Earlier quoted context omitted.
Waiting until Trump discovers that the earth rotation service exists and forces them to insert a negative leap second just because he can.
Oh thank God I thought I was going to make it through a thread on leap seconds without a political discussion
The idea that if being dark at 12pm in 20k years will bother anyone is absurd. The shift will happen so slowly that the only people who will even realize it happened are historians and history buffs. Really the idea that there will enough civilizational continuity that our current timekeeping infrastructure and systems will continue unbroken for that long is insane.
Changing a global time system is not a trivial task. We’re still using a calendar developed over 400 years ago and just making minor tweaks. Without some central global authority, change is unlikely. And even with that, it would be extraordinary disruptive. The middle for the day, on our time keeping devices, being light outside goes all the way back to the first sundials over 3,000 years ago. Small and regular maint…
Earlier quoted context omitted.
IMHO the correct way to handle leap seconds would have been at the same layer as timezones, i.e. a display-only thing. Timezone databases are regularly updated, you push out leap second updates there. In the worst case, people's clocks are off by one second but all the underlying timing logic doesn't crash.
you can use TAI (international atomic time, basically UTC without leap seconds) if you want to be serious about it I'm a fan but it's rare for anyone else to agree!
Earlier quoted context omitted.
Timezones have nothing to do with UTC or unix time. Timezones only come into play when you convert between to other timezones.
Sure; but I happen to be one of the dozens of people who do not live in UTC. So you have to do the conversion at some point _anyway_. If your app presents me data making the assumption that _my_ day is always 86400s, it will be _wrong_.
Computer systems (most importantly, UNIX) should've been using TAI [0] from the beginning. Human-readable time in turn should be computed from it using periodically updated time zones database which would include offset between TAI and UTC. By eliminating leap seconds we effectively re-invented TAI with a weird offset. While I am in favor of eliminating leap seconds as a hacky way to fix the current mess, it's sad to…
Now, if I cannot really add a month anymore (and I cannot in TAI, because months don't even really exist in TAI, since TAI isn't a solar year) in my internal time format, all that convenience goes away. I now must always worry about leap seconds and timezones and all the stuff I don't really need to think about in the vast majority of cases.
…Yeah, well, I'm really not sure. I am not convinced, and am honestly kinda relieved by the fact I won't have to find out. But it's an interesting point nevertheless. And, no, UTC w/o leap seconds is not the same thing. In fact, UTC w/o leap seconds is kinda the polar opposite: it's clearly the wrong abstraction, because it ignores the (not even so hard) problem somebody doesn't want to deal with, which doesn't really go away, but is very practical.
Responding to a deleted comment: > ... the "invisible infrastructure" of the web; balancing historical accuracy with the technical need to minimize zone fragmentation is a much more complex trade-off than it appears on the surface ... The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely. At $wo…
> The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely. There is some talk of eliminating the leap second, which would over time have the Earth and sun diverge with regards to noon and such. One 'answer' to this concern is to have a 'leap hour' or something in the future (some future generation…
For the time of Julius Caesar, about 3 more days would have been needed, which would have made the Christmas coincident with the Winter Solstice, and which would have made much more sense.
Responding to a deleted comment: > ... the "invisible infrastructure" of the web; balancing historical accuracy with the technical need to minimize zone fragmentation is a much more complex trade-off than it appears on the surface ... The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely. At $wo…
> The complexity goes up tremendously if some condition is rarely encountered: eg leap second. This means it gets pushed to a "corner case" and tested more lightly and more rarely. There is some talk of eliminating the leap second, which would over time have the Earth and sun diverge with regards to noon and such. One 'answer' to this concern is to have a 'leap hour' or something in the future (some future generation…
Note that the equinoxes and solstices are officially supposed to be on the 25th. By the time of Julius Caesar, that had diverged, but the divergence in reality made no impact on the date of the official solstice. The Gregorian calendar could easily have put the solstices back on the 25th, but chose not to.
Earlier quoted context omitted.
Yeah. There’s also the issue that the earth’s rotation is slowing down, so over the long term leap seconds would become more and more frequent. There’s a point when the earth is slow enough that leap seconds need to happen nearly every month, and by that point they are no longer a workable solution to the problem. That is expected to take a few thousand years, comparable to the point where a leap hour would be needed…
So some future generations might get 23 hour days? That’s gonna be an interesting problem to solve for calendar implementations
The dinosaurs had days with fewer hours than us.
Earlier quoted context omitted.
So some future generations might get 23 hour days? That’s gonna be an interesting problem to solve for calendar implementations
As another poster already said, there will be 25-hour days at some time. The dinosaurs had days with fewer hours than us.
Now we have locked in second extremely hard underpinning all of our measurements. But you could consider that you have same number of hours in a day and length of those hours has changed...
Earlier quoted context omitted.
you can use TAI (international atomic time, basically UTC without leap seconds) if you want to be serious about it I'm a fan but it's rare for anyone else to agree!
The problem with TAI is that the rest of the world uses UTC. So you can use TAI on a small island and then you have to convert to and from UTC. My hobby kernel is based on TAI internally. And it constantly converts to and from UTC.
As you say, what the computer should maintain internally and for communication with other computers, not with humans, is only true time and not other quantities, like the angles between Earth, Sun and stars.
Only TAI is true time, while "universal time" is an angle and "universal time coordinated" (UTC) and its derivatives are some weird hybrid quantities that can be computed from times and angles.
The conversions between true time and various kinds of official times used by humans are very complex and they should be handled in a single place, not in various places that may handle time zones and discrepancies between UTC and TAI and various other "times", e.g. UT2, UT1 etc.