3 ms·

It's weird to talk about "switching" to atomic time. If you want seconds to always go 58,59,0, and you want time to always increment 1 second at a time, then UT

It's weird to talk about "switching" to atomic time. If you want seconds to always go 58,59,0, and you want time to always increment 1 second at a time, then UTC has never been appropriate. People who need to measure time this way should already be using TAI or GPS Time (which do this). Many people already do this, there's no "switching" needed. However, most civilian applications want a time that is synchronized, to bounded degree, to the Earth's rotation. UTC has leap seconds, which are occasionally added or removed, to make that happen. There's been a push for removing leap seconds from UTC, because that'd be convenient for computers. But no one's figured out how to change the Earth's speed to match this new definition of UTC :-). So if we want time-of-day to be related to the position of the sun in the sky, adjustments like leap seconds are necessary.

segfaultbuserr 6y ago
> It's weird to talk about "switching" to atomic time. The biggest reason to describe it as "switching from UTC to TAI" (at least for me) is due to Unix time. Unix time is an elegant concept at first glance, ideally it's a free-running, monotonic counter that abstracts us away from timezone problems, an unambiguous representation of time. You only adjust the timezone settings or the timezone database, the time itself is never adjusted. Unfortunately, using UTC rather than TAI as Unix time's foundation is a fatal mistake. As Unix time cannot represent leap seconds, all the previous advantages break down - we had to freeze or advance the Unix time itself to compensate for that limitation. If there's a TAI-based "new Unix time", the leap second handling can be simplified a lot. The underlying time is always correct regardless of leap seconds. Sure, a missed leap second notification makes all civilian time faster or slower by 1 second, but the situation is the same for UTC if there's no time synchronization.
HenryKissinger 6y ago
> If you want seconds to always go 58,59,0, and you want time to always increment 1 second at a time, then UTC has never been appropriate Why has it never been appropriate?
- curryst 6y ago
  It's difficult to answer how many seconds are between two times because whether there was a leap second or not is not the result of an algorithm. Leap seconds are added to keep time synchronized to the rotation of the earth (i.e. so noon is when the sun is at its apex). You're better with something like epoch time because the duration between two times is always the absolute value of their subtraction. You don't have to store a chart to figure out whether the difference in wall time between 3:03:03 and 03:03:05 is 2 seconds or if there was a leap second and it should be 3 seconds. You can do it, but you have to check the behavior of all your libraries. Which isn't fun. And make sure that somebody doesn't do an optimization that switches the behavior at some point.
- dwheeler 6y ago
  > Why has it never been appropriate? Because UTC has never worked that way. UTC is an international standard for a "time of day" standard where every second is exactly one second long and is boundedly synchronized to the rotation of the Earth. But the Earth wobbles. The UTC solution is to occasionally add or remove leap seconds, so sometimes you see 58, 59, 60, 0, and we might someday see 58,0. People complain that "leap seconds are hard" but there's a reason for them. Here are your options: * If you want to always have 58,59,0, and you don't really care that time always increments exactly 1 second per second, then you can keep the time synchronized with Earth's rotation by smearing the time or having the time "jump" a little bit around leap seconds. This is what actually happens in many Unix systems. When we get near a leap second, the "seconds" are briefly not quite correct. It's a bounded error of a second or less and doesn't accumulate. For most people this error is just fine, which is why Unix time works for most people. * If you want to always have 58,59,0, and you DO really care that time increments exactly 1 second per second, then don't keep the "time of day" the time synchronized with Earth's rotation. That's what TAI and GPS time do. But most people feel that ordinary civilian "time of day" should have some relationship to the position of the sun in the sky, which is why this is not the normal civilian "time of day" value. * If you want to always have 58,59,0, AND you want time increments of exactly 1 second per second, AND you want time synchronized with Earth's rotation, then you need to regulate the Earth's actual rotational speed. I'm not sure how anyone would do that, but I suspect that will be very expensive :-).

segfaultbuserr 6y ago

> It's weird to talk about "switching" to atomic time. The biggest reason to describe it as "switching from UTC to TAI" (at least for me) is due to Unix time. Unix time is an elegant concept at first glance, ideally it's a free-running, monotonic counter that abstracts us away from timezone problems, an unambiguous representation of time. You only adjust the timezone settings or the timezone database, the time itself is never adjusted. Unfortunately, using UTC rather than TAI as Unix time's foundation is a fatal mistake. As Unix time cannot represent leap seconds, all the previous advantages break down - we had to freeze or advance the Unix time itself to compensate for that limitation. If there's a TAI-based "new Unix time", the leap second handling can be simplified a lot. The underlying time is always correct regardless of leap seconds. Sure, a missed leap second notification makes all civilian time faster or slower by 1 second, but the situation is the same for UTC if there's no time synchronization.

HenryKissinger 6y ago

> If you want seconds to always go 58,59,0, and you want time to always increment 1 second at a time, then UTC has never been appropriate Why has it never been appropriate?

curryst 6y ago
It's difficult to answer how many seconds are between two times because whether there was a leap second or not is not the result of an algorithm. Leap seconds are added to keep time synchronized to the rotation of the earth (i.e. so noon is when the sun is at its apex). You're better with something like epoch time because the duration between two times is always the absolute value of their subtraction. You don't have to store a chart to figure out whether the difference in wall time between 3:03:03 and 03:03:05 is 2 seconds or if there was a leap second and it should be 3 seconds. You can do it, but you have to check the behavior of all your libraries. Which isn't fun. And make sure that somebody doesn't do an optimization that switches the behavior at some point.
dwheeler 6y ago
> Why has it never been appropriate? Because UTC has never worked that way. UTC is an international standard for a "time of day" standard where every second is exactly one second long and is boundedly synchronized to the rotation of the Earth. But the Earth wobbles. The UTC solution is to occasionally add or remove leap seconds, so sometimes you see 58, 59, 60, 0, and we might someday see 58,0. People complain that "leap seconds are hard" but there's a reason for them. Here are your options: * If you want to always have 58,59,0, and you don't really care that time always increments exactly 1 second per second, then you can keep the time synchronized with Earth's rotation by smearing the time or having the time "jump" a little bit around leap seconds. This is what actually happens in many Unix systems. When we get near a leap second, the "seconds" are briefly not quite correct. It's a bounded error of a second or less and doesn't accumulate. For most people this error is just fine, which is why Unix time works for most people. * If you want to always have 58,59,0, and you DO really care that time increments exactly 1 second per second, then don't keep the "time of day" the time synchronized with Earth's rotation. That's what TAI and GPS time do. But most people feel that ordinary civilian "time of day" should have some relationship to the position of the sun in the sky, which is why this is not the normal civilian "time of day" value. * If you want to always have 58,59,0, AND you want time increments of exactly 1 second per second, AND you want time synchronized with Earth's rotation, then you need to regulate the Earth's actual rotational speed. I'm not sure how anyone would do that, but I suspect that will be very expensive :-).