4 ms·

> 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

> 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 :-).

> 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 :-).