4 ms·

Time zones and leap seconds are fundamentally different kinds of adjustments. Time zones are intrinsically a synthetic concept: they're (basically) just differ

by dap 12y ago

Time zones and leap seconds are fundamentally different kinds of adjustments. Time zones are intrinsically a synthetic concept: they're (basically) just different views on the same canonical (UTC) time, based on arbitrary, regional, human-level notions. A leap second is an adjustment to the canonical time itself. In a pedantic sense, that's a synthetic concept too, but it's intended to model a real physical process: the earth's rotation. In the case of a leap second, that process has actually changed, and the time in all time zones is affected. Another problem is that we don't know what leap seconds will be added until six months ahead of time. With the current system, if you calculate something for a time that's a year away, it will still be correct if a leap second is added. If you attempt to deal with leap seconds via time zones, then a timestamp calculated before the addition of a leap second will become incorrect when the leap second is added. It's easy to imagine this causing issues just as serious as the ones we have today. Both approaches are error prone in various cases, but at least today it's possible to write correct code that won't be broken by the addition of a leap second.

adamtj 12y ago
I disagree. Leap seconds are no more synthetic than timezones. As I'll explain, they are used for very similar purposes. Recognizing that means we have only one problem, not two. We can solve that one problem with existing code and processes with very few, if any changes. With no extra work, it also elegantly sidesteps the problem of being unable reliably predict when leap seconds will occur. Leap seconds exist because we want the sun to be in the same position at the same time of day regardless of what year it is, despite the fact that the earth's rotation is slowing down. Timezones exist because we want the sun to be in the same position at the same time of day, regardless of where we are on the globe. We can't reliably predict leap seconds in advance because the slowing of the earth's rotation is variable. We can't reliably predict timezone offsets in advance because legislatures are fickle things. We can no more command politicians to stop meddling than we can command the earth to stop slowing down. Time is a natural phenomenon. It proceeds smoothly at a constant rate. (Ok, relativity. Still...) But, we want our clocks to measure more than just the passage of time. We want them to also indicate the position of the sun relative to where we're standing and what day it is. That causes discrepancies which give rise to time zones. Thus, we need to distinguish between a globaltime that is the same for everybody on earth and various localtime adjustments for convenience. We generally use UTC as a globaltime standard. The problem with that is that UTC isn't smooth or constant because of leap seconds. Our localtime adjustments are difficult enough. We also have to deal with adjustments to our localtime adjustments. It's a hard problem, but a mostly solved one. Unfortunately, leap seconds mean we have the exact same difficulties in our underlying globaltime standard. We're solving the same hard problems twice, in different ways. I'm suggesting that instead we use a nicer globaltime standard and put all our adjustments and our adjustment adjustments into the existing localtime offset calculations. We want timezones, so we need the complexities of implementing localtime. We might as well reuse that solution to deal with leap seconds too, since they're basically the same kind of thing. You're right that with TAI there would be difficulties with calculating times in the future, but we already have those difficulties in a slightly different form. The nature of the difficulties would change, but the change would generally simplify things. Currently, if you specify a UTC timestamp for a future event, the _duration_ between now and then will vary depending on how many leap seconds there are. However, the globaltime and localtime _timestamps_ would remain constant, regardless of leap secords. If instead we switched to TAI for our globaltime standard, both the duration and globaltime timestamps would remain constant, and only the localtime timestamp would change. The unchanging timestamps might make it seem like UTC is better, but that's wrong. The timestamps only _appear_ constant. When those timestamps actually take place depends on leap seconds which can't be known very far in advance. For example, suppose Alice and Bob are trying to coordinate an activity specified by a UTC timestamp. Neither can know in advance how long to wait, so they can't just set timers. If Alice accounts for all leap seconds but Bob misses one, his clock will be wrong and he'll start early. If instead they used a TAI timestamp, then they wouldn't have any problems. They could just set a timer. Or, they could base their activities on their TAI globaltime clocks. Or, they could also use their localtime clocks. Bob missed the leap second, so his localtime is a second fast, but he would also think the event starts a second later. The errors would cancel and he wouldn't make a mistake. When Alice applied the leap second to her offset, she would also need to re-compute the now-changed localtime timestamp of the event, but computers are really good at such things. She could also write down the localtime timestamp of the event with an offset. If she applied the leap second to her localtime clock, but not her old pre-computed timestamp for the event, the clock and the timestamp would have different offsets. She would have to convert between the offsets in the same way she would have to convert between timestamps in different timezones. Leap seconds are the same kind of problem as timezones. We already know how to deal with timezones. We should simplify things and use that one solution for both problems.

by dap 12y ago

adamtj 12y ago

I disagree. Leap seconds are no more synthetic than timezones. As I'll explain, they are used for very similar purposes. Recognizing that means we have only one problem, not two. We can solve that one problem with existing code and processes with very few, if any changes. With no extra work, it also elegantly sidesteps the problem of being unable reliably predict when leap seconds will occur. Leap seconds exist because we want the sun to be in the same position at the same time of day regardless of what year it is, despite the fact that the earth's rotation is slowing down. Timezones exist because we want the sun to be in the same position at the same time of day, regardless of where we are on the globe. We can't reliably predict leap seconds in advance because the slowing of the earth's rotation is variable. We can't reliably predict timezone offsets in advance because legislatures are fickle things. We can no more command politicians to stop meddling than we can command the earth to stop slowing down. Time is a natural phenomenon. It proceeds smoothly at a constant rate. (Ok, relativity. Still...) But, we want our clocks to measure more than just the passage of time. We want them to also indicate the position of the sun relative to where we're standing and what day it is. That causes discrepancies which give rise to time zones. Thus, we need to distinguish between a globaltime that is the same for everybody on earth and various localtime adjustments for convenience. We generally use UTC as a globaltime standard. The problem with that is that UTC isn't smooth or constant because of leap seconds. Our localtime adjustments are difficult enough. We also have to deal with adjustments to our localtime adjustments. It's a hard problem, but a mostly solved one. Unfortunately, leap seconds mean we have the exact same difficulties in our underlying globaltime standard. We're solving the same hard problems twice, in different ways. I'm suggesting that instead we use a nicer globaltime standard and put all our adjustments and our adjustment adjustments into the existing localtime offset calculations. We want timezones, so we need the complexities of implementing localtime. We might as well reuse that solution to deal with leap seconds too, since they're basically the same kind of thing. You're right that with TAI there would be difficulties with calculating times in the future, but we already have those difficulties in a slightly different form. The nature of the difficulties would change, but the change would generally simplify things. Currently, if you specify a UTC timestamp for a future event, the _duration_ between now and then will vary depending on how many leap seconds there are. However, the globaltime and localtime _timestamps_ would remain constant, regardless of leap secords. If instead we switched to TAI for our globaltime standard, both the duration and globaltime timestamps would remain constant, and only the localtime timestamp would change. The unchanging timestamps might make it seem like UTC is better, but that's wrong. The timestamps only _appear_ constant. When those timestamps actually take place depends on leap seconds which can't be known very far in advance. For example, suppose Alice and Bob are trying to coordinate an activity specified by a UTC timestamp. Neither can know in advance how long to wait, so they can't just set timers. If Alice accounts for all leap seconds but Bob misses one, his clock will be wrong and he'll start early. If instead they used a TAI timestamp, then they wouldn't have any problems. They could just set a timer. Or, they could base their activities on their TAI globaltime clocks. Or, they could also use their localtime clocks. Bob missed the leap second, so his localtime is a second fast, but he would also think the event starts a second later. The errors would cancel and he wouldn't make a mistake. When Alice applied the leap second to her offset, she would also need to re-compute the now-changed localtime timestamp of the event, but computers are really good at such things. She could also write down the localtime timestamp of the event with an offset. If she applied the leap second to her localtime clock, but not her old pre-computed timestamp for the event, the clock and the timestamp would have different offsets. She would have to convert between the offsets in the same way she would have to convert between timestamps in different timezones. Leap seconds are the same kind of problem as timezones. We already know how to deal with timezones. We should simplify things and use that one solution for both problems.