6 ms·

Why don't we just switch from UTC to TAI and put the leap seconds in our localtime offsets? It makes all the problems go away, or else reduces them to problems

by adamtj 12y ago

Why don't we just switch from UTC to TAI and put the leap seconds in our localtime offsets? It makes all the problems go away, or else reduces them to problems we've already solved for handling daylight saving time. If you think about it, leap seconds are no different than daylight saving time. The only differences are that daylight saving time usually has 1-hour granularity and is occasionally redefined by your government, where leap seconds have 1-second granularity and are occasionally redefined by Mother Nature. We already know how to deal with repeating seconds and minutes (alternatively, with minutes or hours that are too long). Those happen during daylight saving time changes, but the ambiguity disappears when switching to UTC. We already record timestamps and communicate with UTC, applying a localtime offset for display or user input. That's a solved problem. Further, we know how to change the localtime offset. Most timezones do that twice a year. We also know how to handle timezone definition changes because ignorant legislatures sometimes modify when the daylight saving time switches occur. So, why don't we switch from UTC to TAI as an underlying time standard? When UTC leap seconds occur, we can treat them somewhat like a government redefining its timezones. US Eastern Time then changes from "TAI-05:00:35/TAI-04:00:35" to "TAI-05:00:36/TAI-04:00:36". If two UTC clocks are synchronized, then one accounts for a leap second and the other misses it, the clocks will no longer be synchronized. If they were TAI clocks, they would still be synchronized and both would still record and communicate correct timestamps. It's just that one would display localtime incorrectly. But, you would immediately know that was the case when you see that the offset is a second behind. Missing a leap second would be like having your computer is set to the wrong timezone, and would be just as easy to fix.

themodelplumber 12y ago
How does the system-wide workload of changing from UTC to TAI compare to adding the leap second? No idea about this stuff myself, just curious.
- scott_karana 12y ago
  I think TAI is continuous, unlike UTC, so you can continue auto-incrementing timers without leap seconds and breakages, and just apply the leap-second to rendered time, not accounted time.
- cnvogel 12y ago
  Workload is pretty low in either case... Here's the function in the Linux-Kernel that's counting the seconds. It's actually not specified if this function is called exactly every second, or more often, or less often. It just overflows accumulated nanoseconds to seconds: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/time/timekeeping.c#n1511 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... The only leap-second specific thing in it is the function second_overflow() called in the line linked above, it's implementation is linked below. seconds_overflow() checks if a flag updated by NTP which means "there will be a (positive or negative) leap second at the end of today" (bits in time_state) is active, and if that's the case the last second will be repeated, or skipped. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/time/ntp.c#n374 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... So, computationally, keeping the general complexity of timekeeping in mind, leap second processing is completely insignificant, as evident by the comparatively tiny second_overflow() function.
skrebbel 12y ago
Because humans. Remember how confusing and difficult to find those bugs are where you forget to convert timezones that are, say, <3 hours away from one another? This must be very familiar especially to all African and European coders, where we're caught by this every time we forget to convert to/from UTC somewhere. It's easy to not notice it, while coding with some test data, when your software displays a time only one or two hours off. I bet many UK coders only notice their bug when summer begins. I'm not sure whether you valley people recognize this as well, but I'm sure you can imagine. Now, instead, imagine things being only a few seconds off, instead of entire hours. How big is the chance that the bug would be caught before things hit production? What if, in some cases, seconds actually matter? I think it's just asking for trouble. To me, this is a bit like proposing binary protocols and not text protocols because it's obviously technically superior. It's a good idea until you factor in that software is made by humans.
- tejaswiy 12y ago
  I don't follow. Won't you have all the issues you mentioned by storing timestamps in UTC? Instead of converting from UTC to Local time, you'll be converting from TAI to Local time.
- adamtj 12y ago
  > Now, instead, imagine things being only a few seconds off, instead of entire hours. No, and yes, and anyway it doesn't matter. No, that wouldn't be the case. If you mess up the local->global conversion, you'd still be hours off, not just seconds. Realistically, we would probably need to define TAI2 = TAI + 35 seconds and then switch to that. Then the only immediate change would be that we'd stop adding the leap second flag to NTP updates. If you were doing UTC conversions correctly before, you'd automatically be doing TAI2 conversions correctly after, but if you mess up that conversion, you'll still be hours off. But yes, such a change would introduce a new problem: Software or systems that are not updated to handle leap seconds in offsets might display localtime a second or two off. Still, it wouldn't matter much. Non-TAI2 systems might display localtime a second or two off, but their clocks would still be correctly synchronized. Having an incorrect offset would be like inadvertently defining your own custom timezone. Nobody else would care about your timezone (whether it's a standard one or not), because you'd be communicating with them using global time based on your correctly synchronized clock.
kale 12y ago
I haven't done this for any type of crucial system, but I use GPS time if I want a really accurate time reference (I dabble with ham radio and satellites). GPS time is a few seconds off from UTC due to GPS time not recognizing leap seconds. It's fairly trivial to add the seconds to get UTC very accurately, or even record time in GPS time, and do the calculations to UTC or local time after-the-fact (if needed). I like this idea.
- cnvogel 12y ago
  Even better, GPS itself is sending out the exact UTC offset (and start of validity/moment of insertion of leap seconds)... http://www.losangeles.af.mil/shared/media/document/AFD-100813-045.pdf http://www.losangeles.af.mil/shared/media/document/AFD-10081... §20.3.3.5.2.4
- masklinn 12y ago
  > GPS time is a few seconds off from UTC due to GPS time not recognizing leap seconds. GPS time has a fixed 19s offset to TAI, so in essence you're already using TAI.
Matumio 12y ago
The more reasonable thing to do would be to just forget about leap seconds altogether, not to put them elsewhere. Who cares if midday happens at 12:00:00 or at 12:00:30? Those who do need to add their exact longitude anyway, and they don't like time jumping around either. Human culture can adapt to a slow drift (over centuries) of the meaning of 08:00.
- lostlogin 12y ago
  "Due to inflationary pressures the standard work day has been extended another hour". I didn't downvote but suggesting a fudge factor is never going to fly around here!
  - Matumio 12y ago
    Fudge factor? What I meant to suggest is to just define that UTC is now equal to TAI, and forget about the offset (set leap seconds to zero, or drive slowly towards zero if required).
- DenisM 12y ago
  We could also accumulate leap seconds and release them as leap minutes once a century or so.
  - Matumio 12y ago
    An actual proposal was to wait until an hour has accumulated and then change time zones.
    - deleted 12y ago
      [deleted]
  - organsnyder 12y ago
    I like the current system better. They happen often enough that software is (or should be) written with them in mind. Otherwise, we'd have y2k-style scrambling every time they occurred (since it would be infrequent enough that the pain of the experience would be dulled with time).
kevin_nisbet 12y ago
I don't think this approach will really work, and could cause a significant amount of issues on an implementation level. While it may work in theory, changing all the software would be a huge pain and it would be more difficult to mentally model. 1. I probably make the mental conversion between UTC, and EST, EDT, PST, etc several thousand times a year, which is very strait forward to do with an hour offset. However, doing these mental conversions with 4 hours and 3 seconds (think after a few changes) or 3 hours, 59 minutes, and 57 seconds will make mental alignment of data in different offsets massively more difficult. While I'm a huge proponent of representing all our systems in UTC time, it's just not a reality that exists today. Also, I see many peers fail this conversion often enough, that adding complexity here would be costly. 2. Some of the protocols used for transmitting time offset from UTC are only capable of a resolution of 15 minutes. If I remember correctly, all current 3GPP standards do this, as the wireless protocols for cellular are highly optimized for small message sizes, they do not currently encode a higher resolution than 15 minutes. This means that today, a cellular network cannot send your phone a time offset from UTC more precise than 15 minutes, and to do so would require a change in standards. This also means, that likely no phone on the market today would be capable of reflecting these time differences. While I don't have a perfect alternative, I did like the idea of abolishing the concept of a leap second itself. Meaning, that it is more important that time count forward at a steady rate, from a computation perspective, and that adjustments to re-synchronize with the slight changes in the earths rotation should not be taken at all. I can't think of any downsides with this approach off hand or from previous readings, but I'm sure it creates it's own problems in certain problem spaces I'm not familiar with.
bumbledraven 12y ago
I think this is the approach recommended by djb in http://cr.yp.to/proto/utctai.html http://cr.yp.to/proto/utctai.html
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.
jleader 12y ago
Steve Allen of Lick Observatory has over the years maintained a site discussing the problems of leap seconds (including the internal inconsistencies of POSIX time-related specifications): http://www.ucolick.org/~sla/leapsecs/ http://www.ucolick.org/~sla/leapsecs/. There's a lot of history, and a lot of confusion and conflict among the various standards bodies. It does sound like getting rid of leap seconds one way or another might be the best approach.
sopooneo 12y ago
So that you can calculate the stamp for given date/times in advance. Edit: This depends on two (currently true) assumptions. (1) We are going to have leap seconds. (2) We will not know far in advance when they will be.
ademarre 12y ago
I like the idea of presenting leap seconds as a change in timezone or time offset. But instead of redefining all the UTC-offset timezones, e.g. redefining EST/EDT from UTC-5/UTC-4 to TAI-05:00:35/TAI-04:00:35, what if we redefined only UTC in terms of an offset from TAI? I think this is actually equivalent to what we have today, but it makes the relationship to TAI more obvious, and it should be easier than leap seconds for developers to understand, because they can reuse their cognitive models for time offsets. So leap seconds simply gets re-branded. Instead of saying 'a positive leap second will be introduced at the end of June 2015.' We'll say 'on 1 July 2015 00:00:00 UTC, UTC time will move from TAI-00:00:35 to TAI-00:00:36.' ADD: I suppose this is more than a "re-branding", as it results in the abolishment of second 60. Under the current system, with leap seconds: 2015-06-30 23:59:59 UTC = 2015-07-01 00:00:34 TAI 2015-06-30 23:59:60 UTC = 2015-07-01 00:00:35 TAI 2015-07-01 00:00:00 UTC = 2015-07-01 00:00:36 TAI Under a system where UTC is a TAI offset, second 59 gets repeated: 2015-06-30 23:59:59 UTC = 2015-07-01 00:00:34 TAI 2015-06-30 23:59:59 UTC = 2015-07-01 00:00:35 TAI 2015-07-01 00:00:00 UTC = 2015-07-01 00:00:36 TAI
friendzis 12y ago
There are also whole leap days once every four years
- RIMR 12y ago
  Not quite that simple: if (year is not divisible by 4) then (it is a common year) else if (year is not divisible by 100) then (it is a leap year) else if (year is not divisible by 400) then (it is a common year) else (it is a leap year)

by adamtj 12y ago

themodelplumber 12y ago

How does the system-wide workload of changing from UTC to TAI compare to adding the leap second? No idea about this stuff myself, just curious.

scott_karana 12y ago
I think TAI is continuous, unlike UTC, so you can continue auto-incrementing timers without leap seconds and breakages, and just apply the leap-second to rendered time, not accounted time.
cnvogel 12y ago
Workload is pretty low in either case... Here's the function in the Linux-Kernel that's counting the seconds. It's actually not specified if this function is called exactly every second, or more often, or less often. It just overflows accumulated nanoseconds to seconds: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/time/timekeeping.c#n1511 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... The only leap-second specific thing in it is the function second_overflow() called in the line linked above, it's implementation is linked below. seconds_overflow() checks if a flag updated by NTP which means "there will be a (positive or negative) leap second at the end of today" (bits in time_state) is active, and if that's the case the last second will be repeated, or skipped. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/kernel/time/ntp.c#n374 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.... So, computationally, keeping the general complexity of timekeeping in mind, leap second processing is completely insignificant, as evident by the comparatively tiny second_overflow() function.

skrebbel 12y ago

Because humans. Remember how confusing and difficult to find those bugs are where you forget to convert timezones that are, say, <3 hours away from one another? This must be very familiar especially to all African and European coders, where we're caught by this every time we forget to convert to/from UTC somewhere. It's easy to not notice it, while coding with some test data, when your software displays a time only one or two hours off. I bet many UK coders only notice their bug when summer begins. I'm not sure whether you valley people recognize this as well, but I'm sure you can imagine. Now, instead, imagine things being only a few seconds off, instead of entire hours. How big is the chance that the bug would be caught before things hit production? What if, in some cases, seconds actually matter? I think it's just asking for trouble. To me, this is a bit like proposing binary protocols and not text protocols because it's obviously technically superior. It's a good idea until you factor in that software is made by humans.

tejaswiy 12y ago
I don't follow. Won't you have all the issues you mentioned by storing timestamps in UTC? Instead of converting from UTC to Local time, you'll be converting from TAI to Local time.
adamtj 12y ago
> Now, instead, imagine things being only a few seconds off, instead of entire hours. No, and yes, and anyway it doesn't matter. No, that wouldn't be the case. If you mess up the local->global conversion, you'd still be hours off, not just seconds. Realistically, we would probably need to define TAI2 = TAI + 35 seconds and then switch to that. Then the only immediate change would be that we'd stop adding the leap second flag to NTP updates. If you were doing UTC conversions correctly before, you'd automatically be doing TAI2 conversions correctly after, but if you mess up that conversion, you'll still be hours off. But yes, such a change would introduce a new problem: Software or systems that are not updated to handle leap seconds in offsets might display localtime a second or two off. Still, it wouldn't matter much. Non-TAI2 systems might display localtime a second or two off, but their clocks would still be correctly synchronized. Having an incorrect offset would be like inadvertently defining your own custom timezone. Nobody else would care about your timezone (whether it's a standard one or not), because you'd be communicating with them using global time based on your correctly synchronized clock.

kale 12y ago

I haven't done this for any type of crucial system, but I use GPS time if I want a really accurate time reference (I dabble with ham radio and satellites). GPS time is a few seconds off from UTC due to GPS time not recognizing leap seconds. It's fairly trivial to add the seconds to get UTC very accurately, or even record time in GPS time, and do the calculations to UTC or local time after-the-fact (if needed). I like this idea.

cnvogel 12y ago
Even better, GPS itself is sending out the exact UTC offset (and start of validity/moment of insertion of leap seconds)... http://www.losangeles.af.mil/shared/media/document/AFD-100813-045.pdf http://www.losangeles.af.mil/shared/media/document/AFD-10081... §20.3.3.5.2.4
masklinn 12y ago
> GPS time is a few seconds off from UTC due to GPS time not recognizing leap seconds. GPS time has a fixed 19s offset to TAI, so in essence you're already using TAI.

Matumio 12y ago

The more reasonable thing to do would be to just forget about leap seconds altogether, not to put them elsewhere. Who cares if midday happens at 12:00:00 or at 12:00:30? Those who do need to add their exact longitude anyway, and they don't like time jumping around either. Human culture can adapt to a slow drift (over centuries) of the meaning of 08:00.

lostlogin 12y ago
"Due to inflationary pressures the standard work day has been extended another hour". I didn't downvote but suggesting a fudge factor is never going to fly around here!
- Matumio 12y ago
  Fudge factor? What I meant to suggest is to just define that UTC is now equal to TAI, and forget about the offset (set leap seconds to zero, or drive slowly towards zero if required).
DenisM 12y ago
We could also accumulate leap seconds and release them as leap minutes once a century or so.
- Matumio 12y ago
  An actual proposal was to wait until an hour has accumulated and then change time zones.
  - deleted 12y ago
    [deleted]
- organsnyder 12y ago
  I like the current system better. They happen often enough that software is (or should be) written with them in mind. Otherwise, we'd have y2k-style scrambling every time they occurred (since it would be infrequent enough that the pain of the experience would be dulled with time).

kevin_nisbet 12y ago

I don't think this approach will really work, and could cause a significant amount of issues on an implementation level. While it may work in theory, changing all the software would be a huge pain and it would be more difficult to mentally model. 1. I probably make the mental conversion between UTC, and EST, EDT, PST, etc several thousand times a year, which is very strait forward to do with an hour offset. However, doing these mental conversions with 4 hours and 3 seconds (think after a few changes) or 3 hours, 59 minutes, and 57 seconds will make mental alignment of data in different offsets massively more difficult. While I'm a huge proponent of representing all our systems in UTC time, it's just not a reality that exists today. Also, I see many peers fail this conversion often enough, that adding complexity here would be costly. 2. Some of the protocols used for transmitting time offset from UTC are only capable of a resolution of 15 minutes. If I remember correctly, all current 3GPP standards do this, as the wireless protocols for cellular are highly optimized for small message sizes, they do not currently encode a higher resolution than 15 minutes. This means that today, a cellular network cannot send your phone a time offset from UTC more precise than 15 minutes, and to do so would require a change in standards. This also means, that likely no phone on the market today would be capable of reflecting these time differences. While I don't have a perfect alternative, I did like the idea of abolishing the concept of a leap second itself. Meaning, that it is more important that time count forward at a steady rate, from a computation perspective, and that adjustments to re-synchronize with the slight changes in the earths rotation should not be taken at all. I can't think of any downsides with this approach off hand or from previous readings, but I'm sure it creates it's own problems in certain problem spaces I'm not familiar with.

bumbledraven 12y ago

I think this is the approach recommended by djb in http://cr.yp.to/proto/utctai.html http://cr.yp.to/proto/utctai.html

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.

jleader 12y ago

Steve Allen of Lick Observatory has over the years maintained a site discussing the problems of leap seconds (including the internal inconsistencies of POSIX time-related specifications): http://www.ucolick.org/~sla/leapsecs/ http://www.ucolick.org/~sla/leapsecs/. There's a lot of history, and a lot of confusion and conflict among the various standards bodies. It does sound like getting rid of leap seconds one way or another might be the best approach.

sopooneo 12y ago

So that you can calculate the stamp for given date/times in advance. Edit: This depends on two (currently true) assumptions. (1) We are going to have leap seconds. (2) We will not know far in advance when they will be.

ademarre 12y ago

I like the idea of presenting leap seconds as a change in timezone or time offset. But instead of redefining all the UTC-offset timezones, e.g. redefining EST/EDT from UTC-5/UTC-4 to TAI-05:00:35/TAI-04:00:35, what if we redefined only UTC in terms of an offset from TAI? I think this is actually equivalent to what we have today, but it makes the relationship to TAI more obvious, and it should be easier than leap seconds for developers to understand, because they can reuse their cognitive models for time offsets. So leap seconds simply gets re-branded. Instead of saying 'a positive leap second will be introduced at the end of June 2015.' We'll say 'on 1 July 2015 00:00:00 UTC, UTC time will move from TAI-00:00:35 to TAI-00:00:36.' ADD: I suppose this is more than a "re-branding", as it results in the abolishment of second 60. Under the current system, with leap seconds: 2015-06-30 23:59:59 UTC = 2015-07-01 00:00:34 TAI 2015-06-30 23:59:60 UTC = 2015-07-01 00:00:35 TAI 2015-07-01 00:00:00 UTC = 2015-07-01 00:00:36 TAI Under a system where UTC is a TAI offset, second 59 gets repeated: 2015-06-30 23:59:59 UTC = 2015-07-01 00:00:34 TAI 2015-06-30 23:59:59 UTC = 2015-07-01 00:00:35 TAI 2015-07-01 00:00:00 UTC = 2015-07-01 00:00:36 TAI

friendzis 12y ago

There are also whole leap days once every four years

RIMR 12y ago
Not quite that simple: if (year is not divisible by 4) then (it is a common year) else if (year is not divisible by 100) then (it is a leap year) else if (year is not divisible by 400) then (it is a common year) else (it is a leap year)