UTC, leap seconds and computer time
A network time heads-up. There has been a debate raging for some years on whether or not to change Universal Coordinated Time (UTC) to be the same as International Atomic Time (TAI), which is due for a major vote at the ITU-R in January. Previous votes have seen it defeated but it keeps coming back. To explain the background: The rotation of the earth is not precisely the same length of time each year and currently a decison is made every six months whether or not to correct UTC to ensure that midday really is when the sun is at its highest point over the Greenwich meridian, by adding a leap second. 24 have been added over the last 40 years and UTC now differs from TAI by 34 seconds. The proposal, if agreed, will drop this correction and so over a long time the connection between time and the rotation of the earth will be lost. The implication for networks is potentially quite profound. NTP currently supports leap seconds as do GPS satellite time signals and DCF77 radio clocks but if this proposal is agreed that will be turned off. So if you provide time to a system that take a photograph at the same time every day then that will need two time signals, one for TAI and a new one for earth rotation time. Same problem for anything to do with sun rises/falls and tides (though obviously the precision may not be an issue for some years). If you want to read more then this article covers the arguments quite well, though biased like me against the idea: http://www.bloomberg.com/news/2011-12-22/un-vote-could-allow-mankind-to-cont... I'm not sure if NZ has a position on this, but I am trying to find out. cheers Jay PS A reminder about our free NTP service, details at: www.ntp.net.nz PPS If you think this is off-topic for this list then please let me know! -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
On Fri 23 Dec 2011 11:19:12 NZDT +1300, Jay Daley wrote:
There has been a debate raging for some years on whether or not to change Universal Coordinated Time (UTC) to be the same as International Atomic Time (TAI), which is due for a major vote at the ITU-R in January. Previous votes have seen it defeated but it keeps coming back.
The issue is whether to abolish leap seconds, with the reasoning that they may be more trouble than they're worth. It's an international issue of metrology and I doubt it's decided by ITU-R (standardising wireless communications) and certainly not network operators. What you probably mean is that the ITU is trying to make up their mind which side of the fence they want to put their vote, and is thus asking their members for their opinions. I understand anyone is allowed to put their argument of how they're affected and why things therefore should be one way or the other.
The implication for networks is potentially quite profound. NTP currently supports leap seconds as do GPS satellite time signals and DCF77 radio clocks but if this proposal is agreed that will be turned off.
NTP, GPS and DCF77 are time transfer mechanisms that just transfer the time you feed in. If you were to feed in TAI instead of UTC everyone's lounge clock jumps by a few seconds once (or more likely that will be spread out over 1s every so often). Who'll notice? Did anyone notice the last leap second change? The time transfer mechanisms work just the same. Practical questions: Do you actually know what you're getting out of your time reference piece? I know DCF77 gives you central European time (i.e. UTC plus time zone offsets). I'm not sure about NTP - at a guess, it gives out whatever the person running the stratum 1 clock puts in. That can be anything. GPS? Hmm. GPS doesn't even run on TAI, for 2 reasons: 1) There is no clock showing TAI, and GPS runs on an American master clock. That's not TAI, but the difference is probably small. Same goes for DCF77, except that the master clock is German and I happen to know it's participating in TAI. 2) GPS uses TAI + some fixed offset of a few seconds (IIRC 12), that being the UTC offset to TAI at the time GPS was rolled out. So GPS showed UTC, which lasted until the next leap second. When you hook up a GPS receiver to an NTP server, are you sure you know what you're getting? TAI? GPS-time? UTC? Are you sure the receiver applies the current number of leap seconds offset? Does GPS even transmit that information? My computer is NTP synchronised, but I have no way of knowing whether it's TAI, UTC, something in between or something else. If I was doing photography dependent on a certain earth-rotational position I'd use NTP and adjust it so the photo looks good. As long as the time is always the same, it doesn't really matter what it is exactly. How does this affect networks and network operators? If you're operating a network and time synchronisation is that important for your transmission clock signals aren't you operating on TAI already? Because if not, dealing with all those leap seconds doesn't sound like fun. Volker -- Volker Kuhlmann is list0570 with the domain in header. http://volker.dnsalias.net/ Please do not CC list postings to me.
HI Volker Just to be clear: - NTP, GPS and DCF77 all have explicit support for leap seconds so that they are automatically taken care of - in other words equipment that relies on them is using leap seconds automatically, network operators don't need to worry about it, it all works. - Leap seconds are always added at midnight when it takes two seconds to go from 59 to 0 instead of 1. - GPS signals include UTC offset information so the time signal that GPS receivers use (and provide) is UTC by calculation. The only issue with GPS time signals is the deliberate reduction in accuracy of +/- 340 nanoseconds for military purposes. - Global time is synchronised by two-way time and frequency transfer with the BIPM in France. A crude explanation is that the time provided by the various atomic clocks that participate is averaged to make TAI. Hopefully that answers all of your questions. cheers Jay On 23/12/2011, at 2:08 PM, Volker Kuhlmann wrote:
On Fri 23 Dec 2011 11:19:12 NZDT +1300, Jay Daley wrote:
There has been a debate raging for some years on whether or not to change Universal Coordinated Time (UTC) to be the same as International Atomic Time (TAI), which is due for a major vote at the ITU-R in January. Previous votes have seen it defeated but it keeps coming back.
The issue is whether to abolish leap seconds, with the reasoning that they may be more trouble than they're worth. It's an international issue of metrology and I doubt it's decided by ITU-R (standardising wireless communications) and certainly not network operators. What you probably mean is that the ITU is trying to make up their mind which side of the fence they want to put their vote, and is thus asking their members for their opinions. I understand anyone is allowed to put their argument of how they're affected and why things therefore should be one way or the other.
The implication for networks is potentially quite profound. NTP currently supports leap seconds as do GPS satellite time signals and DCF77 radio clocks but if this proposal is agreed that will be turned off.
NTP, GPS and DCF77 are time transfer mechanisms that just transfer the time you feed in. If you were to feed in TAI instead of UTC everyone's lounge clock jumps by a few seconds once (or more likely that will be spread out over 1s every so often). Who'll notice? Did anyone notice the last leap second change? The time transfer mechanisms work just the same.
Practical questions: Do you actually know what you're getting out of your time reference piece? I know DCF77 gives you central European time (i.e. UTC plus time zone offsets). I'm not sure about NTP - at a guess, it gives out whatever the person running the stratum 1 clock puts in. That can be anything. GPS? Hmm. GPS doesn't even run on TAI, for 2 reasons: 1) There is no clock showing TAI, and GPS runs on an American master clock. That's not TAI, but the difference is probably small. Same goes for DCF77, except that the master clock is German and I happen to know it's participating in TAI. 2) GPS uses TAI + some fixed offset of a few seconds (IIRC 12), that being the UTC offset to TAI at the time GPS was rolled out. So GPS showed UTC, which lasted until the next leap second.
When you hook up a GPS receiver to an NTP server, are you sure you know what you're getting? TAI? GPS-time? UTC? Are you sure the receiver applies the current number of leap seconds offset? Does GPS even transmit that information? My computer is NTP synchronised, but I have no way of knowing whether it's TAI, UTC, something in between or something else. If I was doing photography dependent on a certain earth-rotational position I'd use NTP and adjust it so the photo looks good. As long as the time is always the same, it doesn't really matter what it is exactly.
How does this affect networks and network operators? If you're operating a network and time synchronisation is that important for your transmission clock signals aren't you operating on TAI already? Because if not, dealing with all those leap seconds doesn't sound like fun.
Volker
-- Volker Kuhlmann is list0570 with the domain in header. http://volker.dnsalias.net/ Please do not CC list postings to me. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
I came across http://futureofutc.org/ back in August, in case there's interest in further reading. Havn't looked to see how it overlaps with the bloomberg article below. On 23/12/11 11:19, Jay Daley wrote:
A network time heads-up.
There has been a debate raging for some years on whether or not to change Universal Coordinated Time (UTC) to be the same as International Atomic Time (TAI), which is due for a major vote at the ITU-R in January. Previous votes have seen it defeated but it keeps coming back.
*snip*
On 23/12/11 11:19, Jay Daley wrote: [stuff about aligning UTC with TAI] One thing folks should be aware of is that the "UTC" on your computer is not UTC at all. Oh, the /current/ time might be correct, but the way leap seconds are implemented is simply to adjust the clock by a second, not to adjust the representation of the time. Thus, you find that the time stored in your computer is the number of seconds since midnight, 1 January 1970, as if there were no leap seconds inserted. Zero time on Unix and Unix-derived systems is actually 1 Jan 1970 00:00:24 UTC. The Unix time APIs allow for leap seconds, e.g. this extract from a Linux /asctime()/ man page: _tm_sec_ The number of seconds after the minute, normally in the range 0 to 59, but can be up to 60 to allow for leap seconds. but this element of the API has never been implemented. Introducing leap seconds to Unix time in a way that would make this API element correct would actually break stuff, because, for example, time modulo 60 gives seconds past the minute boundary, and introducing leap seconds into the system time would break anything that assumed this was true. It would also create problems when time from a system implementing leap seconds is presented to one that that isn't. The reality is that insertion of a positive leap second involves back-stepping, stopping or slewing the clock. That means for the duration of the adjustment, at least one "second" is not actually a second long. It's a small thing for most protocols (most of us have learned to live with time discontinuities, as they happen due to loss and/or subsequent regain of time synchronisation a lot more often than due to leap seconds ... has anybody else fixed ntpd, and suddenly had their screen-saver kick in?), but the fact remains that leap second are handled in a way that can only be described as introducing an error. On average, a leap second is added every two years -- it varies, there have only been two since 2000, vs one or even two a year through the '70s. At a rate of one every two years, it'll be over three thousand years before the time offset from celestial time reaches half an hour, at which point folks might start to notice. That's rather longer any widely used modern calendar has been codified to any level of accuracy.. My personal view: Stop doing leap seconds for time co-ordination. Publish tables of UTC to celestial time offsets, with suitable libraries and APIs. Make it more accurate than applying leap seconds, so it' s really useful to those who actually care about astronomical position, and can be safely ignored by those who don't. Stop messing with the actual ticker, and live with the 34 second offset to TAI. Just to put this into perspective, at about a quarter past three* in the morning of Tuesday, 19 Jan 2038, 32 bit signed Unix time will roll over. That's in just over 26 years. New industry hires will have to deal with this during their careers. And it's not just a matter of "upgrading" to 64 bit time; you have top deal with 32 bit fields in file systems and various other data storage formats. It'll be Y2K all over again, except harder to explain to the masses. -- don * The exact time of this event depends on what happens with leap seconds.
On 23/12/2011, at 6:45 PM, Don Stokes wrote:
On 23/12/11 11:19, Jay Daley wrote: [stuff about aligning UTC with TAI]
One thing folks should be aware of is that the "UTC" on your computer is not UTC at all. Oh, the current time might be correct, but the way leap seconds are implemented is simply to adjust the clock by a second, not to adjust the representation of the time. Thus, you find that the time stored in your computer is the number of seconds since midnight, 1 January 1970, as if there were no leap seconds inserted.
Zero time on Unix and Unix-derived systems is actually 1 Jan 1970 00:00:24 UTC.
I'm not sure what point you are making here. If you ask a Unix computer conditioned by NTP what the time is it answers with the correct time in UTC. If you ask it how many seconds has elapsed since a particular point then that might not be correct as it does not include leap seconds. But the two uses are very different. If you are doing something that requires second/sub-second precision then either account for leap seconds or use a time source that doesn't use them. Leap second files are readily available and can be transmitted by NTP.
The Unix time APIs allow for leap seconds, e.g. this extract from a Linux asctime() man page: tm_sec The number of seconds after the minute, normally in the range 0 to 59, but can be up to 60 to allow for leap seconds. but this element of the API has never been implemented. Introducing leap seconds to Unix time in a way that would make this API element correct would actually break stuff, because, for example, time modulo 60 gives seconds past the minute boundary, and introducing leap seconds into the system time would break anything that assumed this was true. It would also create problems when time from a system implementing leap seconds is presented to one that that isn't.
The reality is that insertion of a positive leap second involves back-stepping, stopping or slewing the clock. That means for the duration of the adjustment, at least one "second" is not actually a second long. It's a small thing for most protocols (most of us have learned to live with time discontinuities, as they happen due to loss and/or subsequent regain of time synchronisation a lot more often than due to leap seconds ... has anybody else fixed ntpd, and suddenly had their screen-saver kick in?), but the fact remains that leap second are handled in a way that can only be described as introducing an error.
NTP is constantly correcting the clock. Leap seconds are treated like any other large correction. Admittedly this does take a while but as explained above this is only a problem if second/sub-second resolution is needed.
On average, a leap second is added every two years -- it varies, there have only been two since 2000, vs one or even two a year through the '70s. At a rate of one every two years, it'll be over three thousand years before the time offset from celestial time reaches half an hour, at which point folks might start to notice. That's rather longer any widely used modern calendar has been codified to any level of accuracy..
The proposal requires a leap hour to be added after 600 years.
My personal view: Stop doing leap seconds for time co-ordination. Publish tables of UTC to celestial time offsets, with suitable libraries and APIs. Make it more accurate than applying leap seconds, so it' s really useful to those who actually care about astronomical position, and can be safely ignored by those who don't. Stop messing with the actual ticker, and live with the 34 second offset to TAI.
We already have a time system that compensates for leap seconds, so why remove that and then invent a replacement that does the same thing?
Just to put this into perspective, at about a quarter past three* in the morning of Tuesday, 19 Jan 2038, 32 bit signed Unix time will roll over. That's in just over 26 years. New industry hires will have to deal with this during their careers. And it's not just a matter of "upgrading" to 64 bit time; you have top deal with 32 bit fields in file systems and various other data storage formats. It'll be Y2K all over again, except harder to explain to the masses.
Which is the perfect opportunity to implement a new time system that provides all the correctness needed for computers while leaving UTC via NTP alone. cheers Jay
-- don
* The exact time of this event depends on what happens with leap seconds. _______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
On 12/23/2011 11:27 PM, Jay Daley wrote:
The reality is that insertion of a positive leap second involves back-stepping, stopping or slewing the clock. That means for the duration of the adjustment, at least one "second" is not actually a second long. It's a small thing for most protocols (most of us have learned to live with time discontinuities, as they happen due to loss and/or subsequent regain of time synchronisation a lot more often than due to leap seconds ... has anybody else fixed ntpd, and suddenly had their screen-saver kick in?), but the fact remains that leap second are handled in a way that can only be described as introducing an error.
NTP is constantly correcting the clock. Leap seconds are treated like any other large correction. Admittedly this does take a while but as explained above this is only a problem if second/sub-second resolution is needed.
You're conflating two separate functions provided by NTP: regulation and synchronisation. Every externally referenced time system needs a means of regulating it to the external reference. But synchronisation is usually a one-time thing, done at system startup time, or as a remedial action when regulation has failed. The important thing about a regulated clock is that a second, millisecond or microsecond, whatever the resolution of the clock, should takes very close to that measure of wall time to elapse, within a small and preferably well defined margin. Any discontinuity outside those margins represents a failure of regulation. According to the NTPd documentation, "the time is slewed if the offset is less than the step threshold, which is 128 ms by default, and stepped if above the threshold." In other words, a change of a second, such as would occur when adding a leap second, will introduce a discontinuity unless the NTP server slews the source at a rate lower than the slew threshold (.5 ms/second, or 2,000 seconds for a 1 second adjustment). This is an error in clock regulation and should be considered such. Decent stratum-1 NTP servers don't otherwise do this to their clients, and I don't see why a handful of astronomers should demand that they should. Of course what ought to happen is for systems to have a regulated but unsynchronised time "ticker", available for delta time or other non-absolute time calculations, initialised at system startup time and apart from applying a reference, left alone. Then an offset from the base time to the calendar epoch provided for absolute time calculations. I've worked with systems that did in fact do this. But the standard Unix APIs do not separate calendar time from system time. -- don
On Fri, 2011-12-23 at 11:19 +1300, Jay Daley wrote:
A network time heads-up.
There has been a debate raging for some years on whether or not to change Universal Coordinated Time (UTC) to be the same as International Atomic Time (TAI), which is due for a major vote at the ITU-R in January. Previous votes have seen it defeated but it keeps coming back.
To explain the background: The rotation of the earth is not precisely the same length of time each year and currently a decison is made every six months whether or not to correct UTC to ensure that midday really is when the sun is at its highest point over the Greenwich meridian, by adding a leap second. 24 have been added over the last 40 years and UTC now differs from TAI by 34 seconds. The proposal, if agreed, will drop this correction and so over a long time the connection between time and the rotation of the earth will be lost.
The implication for networks is potentially quite profound. NTP currently supports leap seconds as do GPS satellite time signals and DCF77 radio clocks but if this proposal is agreed that will be turned off. So if you provide time to a system that take a photograph at the same time every day then that will need two time signals, one for TAI and a new one for earth rotation time. Same problem for anything to do with sun rises/falls and tides (though obviously the precision may not be an issue for some years).
If you want to read more then this article covers the arguments quite well, though biased like me against the idea: http://www.bloomberg.com/news/2011-12-22/un-vote-could-allow-mankind-to-cont...
I'm not sure if NZ has a position on this, but I am trying to find out.
I don't know if NZ has an opinion on the matter :-) I have my own opinion, and I've been involved in calendaring standards for a few years now, which is the background that I personally bring to the debate :-) My opinion is: We should move leap seconds into their own timezone. Rationale: Handling of leap seconds programmatically is quite complex. Potentially quite costly. And when you write software to handle them correctly you will probably find your software interacting with some other software which doesn't, such as the standard Java 'Calendar' class. Software which handles timezones will[1] already handle arbitrary shifts from UTC, occurring at arbitrary dates and times. Mechanisms exist for sharing timezone definitions which have evolved over some time. Over so long, in fact that the main person responsible has long threatened to retire (and is also being threatened with an unrelated nuisance lawsuit, but don't get me started on that...), and those procedures are finally being enshrined into a more structured process. Balancing all of this experience and existing code for handling timezones against the obscurity and uneven implementation of leap seconds, I think that the world will have a more consistent, accurate and trustable time service if we remove the awkwardness of leap seconds from the standard and put it into it's own timezone.
From my reading we have a period of 600 years or so while the difference remains relatively static, and after that point the actual timezones used in people's daily lives may also begin to have one-off variations which are occasionally applied.
There are many implementation details, of course, and no doubt there will be some grumpy astronomers for a while, but at the end of it we will all have a more robust system. Those astronomers probably often get grumpy when they see code using modulo 86400 to work out the second in the day anyway. Last year I actually wrote a date/time handling library that took full account of leap seconds. I've since removed all of that cruft from it after following this debate for a few months, and I sleep easier at night as a result :-) Regards, Andrew McMillan. [1] or they have bugs, but those bugs should be easier to understand and resolve than bugs in handling leap seconds in other ways. -- ------------------------------------------------------------------------ andrew (AT) morphoss (DOT) com +64(272)DEBIAN ... I have read the INSTRUCTIONS ... ------------------------------------------------------------------------
On 23/12/2011, at 7:11 PM, Andrew McMillan wrote:
I don't know if NZ has an opinion on the matter :-)
I meant the NZ Government and what it would say at ITU-R.
I have my own opinion, and I've been involved in calendaring standards for a few years now, which is the background that I personally bring to the debate :-)
My opinion is:
We should move leap seconds into their own timezone.
Rationale:
Handling of leap seconds programmatically is quite complex. Potentially quite costly. And when you write software to handle them correctly you will probably find your software interacting with some other software which doesn't, such as the standard Java 'Calendar' class.
Software which handles timezones will[1] already handle arbitrary shifts from UTC, occurring at arbitrary dates and times. Mechanisms exist for sharing timezone definitions which have evolved over some time. Over so long, in fact that the main person responsible has long threatened to retire (and is also being threatened with an unrelated nuisance lawsuit, but don't get me started on that...), and those procedures are finally being enshrined into a more structured process.
Balancing all of this experience and existing code for handling timezones against the obscurity and uneven implementation of leap seconds, I think that the world will have a more consistent, accurate and trustable time service if we remove the awkwardness of leap seconds from the standard and put it into it's own timezone.
From my reading we have a period of 600 years or so while the difference remains relatively static, and after that point the actual timezones used in people's daily lives may also begin to have one-off variations which are occasionally applied.
There are many implementation details, of course, and no doubt there will be some grumpy astronomers for a while, but at the end of it we will all have a more robust system. Those astronomers probably often get grumpy when they see code using modulo 86400 to work out the second in the day anyway.
Last year I actually wrote a date/time handling library that took full account of leap seconds. I've since removed all of that cruft from it after following this debate for a few months, and I sleep easier at night as a result :-)
I'm not sure what difference leap seconds make to a calendaring system. Does it matter to a calendaring system that some seconds are actually two seconds long? So long as there is a global time representation then calendaring works. UTC provides this. The beauty of the existing management of leap seconds is that it is transparent for most applications. Writing code to handle them where it is not needed is asking for trouble. cheers Jay
Regards, Andrew McMillan.
[1] or they have bugs, but those bugs should be easier to understand and resolve than bugs in handling leap seconds in other ways.
-- ------------------------------------------------------------------------ andrew (AT) morphoss (DOT) com +64(272)DEBIAN ... I have read the INSTRUCTIONS ... ------------------------------------------------------------------------
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
On 2011-12-23 23:35, Jay Daley wrote: ...
The beauty of the existing management of leap seconds is that it is transparent for most applications. Writing code to handle them where it is not needed is asking for trouble.
I agree. Not inserting leap seconds is logically equivalent to the ancient Babylonian system of defining the year as 360 days, because it had nicer factors than 365. The annual error is smaller but otherwise it's the same logic. Ditto for the Julian versus Gregorian calendar. We shouldn't make reality less convenient by making the calculations more convenient. On the Unix clock runout in 2038 - it is a completely disjoint issue, but just for fun, are people aware that this bug already hit in 2004 when the most significant bit flipped? Any software that was erroneously handling the Unix date as a signed integer broke. There were real, multi-million $ embarassments that never hit the press. Brian
On Fri, 2011-12-23 at 23:35 +1300, Jay Daley wrote:
I'm not sure what difference leap seconds make to a calendaring system. Does it matter to a calendaring system that some seconds are actually two seconds long? So long as there is a global time representation then calendaring works. UTC provides this.
Mostly it's a problem with how to do date arithmetic. Some types of date arithmetic are easiest performed on y/m/d/h/m/s whereas other types are easiest performed on the basis of a continuously incrementing count of time since an epoch. It's really good if both types of calculation produce the 'right' result. A system for scheduling meetings in an office isn't likely to care about leap seconds - it probably doesn't even care about seconds! But the same software can be used for storing schedules for machinery and other things where more precise synchronisation is more important.
The beauty of the existing management of leap seconds is that it is transparent for most applications. Writing code to handle them where it is not needed is asking for trouble.
Yes, I agree, and that's why I think that putting leap seconds into their own timezone is a simple mechanism to provide general access to the information and the adjustment for those applications that need it. It's great that NTP has hacks to handle moving time around while pretending to the client services that leap seconds don't exist, but they *are* hacks. Seconds do pass during that transition, stuff happens that will sometimes want to be recorded with microsecond accuracy, and compared with something else happening elsewhere. Cheers, Andrew. -- ------------------------------------------------------------------------ andrew (AT) morphoss (DOT) com +64(272)DEBIAN Does the turtle move for you? www.kame.net ------------------------------------------------------------------------
At 10:36 a.m. 24/12/2011, Andrew McMillan wrote:
A system for scheduling meetings in an office isn't likely to care about leap seconds - it probably doesn't even care about seconds! But the same software can be used for storing schedules for machinery and other things where more precise synchronisation is more important.
You should consult with the protection engineers at Transpower and the Energy companies. Since 79/80 they have been running time-tagging on events, accurate to sub-second. I forget the accuracy as it was a long time ago now (I was at Westinghouse Automation, who supplied the SI SCADA). The time-tagging was developed from scratch by Westinghouse.. Time tagging is vital for fault forensics like you saw when Huntly dropped off this week. They need to analyse when each circuit breaker tripped or opened, down to the cycle level or below (cycle as in 50Hz). Adding in a second here or there makes a huge difference. The North Island network was seconds away from a 2-3 day outage. Richard
From a computer engineering point of view, who cares about how computers
Hey Jay,
Obviously a lot of food for thought here.
track time, they really don't care what time of the day it is, or what day
it is in the week, they just do their thing. And that''s just like with
the power system, Transpower NZ's grid works day and night and the
protection around it will operate day and night, hey what happened at
Huntly Powerstation the other week, would have happened anytime, it just
happens that we tend to use more electricity during the day.
So, there's two points to this...
1. The amount of time it takes the earth to rotate around it axis
2. The amount of time it takes the earth to orbit around the sun
If I'm correct...
1. It takes 24 Hours for the planet to completely rotate 360 degrees around
it's axis.
2. It takes 365.25 days for the earth to orbit around the sun...
The whole idea of 29th February to happen once every 4 years is to
compensate for the extra time it required for the earth to orbit around the
sun, which has worked well for a number of years and suits me just fine.
OTOH, lengthening then day to compensate for the time for the earth to
orbit around the sun is going to create a lot more problems that it's
worth, for starters lets throw out all the other timezones, and let's write
a script as to when it's time to come to work, brew a coffee, have lunch,
then open a beer. Also, I might as well throw away my navigation charts,
and for those of you that have done at least your PPL cross-country flying
will know where I'm going with this...
I agree with that if anything is devised that it should be it's own
timezone rather than UTC redefined.
On Fri, Dec 23, 2011 at 11:19 AM, Jay Daley
A network time heads-up.
There has been a debate raging for some years on whether or not to change Universal Coordinated Time (UTC) to be the same as International Atomic Time (TAI), which is due for a major vote at the ITU-R in January. Previous votes have seen it defeated but it keeps coming back.
To explain the background: The rotation of the earth is not precisely the same length of time each year and currently a decison is made every six months whether or not to correct UTC to ensure that midday really is when the sun is at its highest point over the Greenwich meridian, by adding a leap second. 24 have been added over the last 40 years and UTC now differs from TAI by 34 seconds. The proposal, if agreed, will drop this correction and so over a long time the connection between time and the rotation of the earth will be lost.
The implication for networks is potentially quite profound. NTP currently supports leap seconds as do GPS satellite time signals and DCF77 radio clocks but if this proposal is agreed that will be turned off. So if you provide time to a system that take a photograph at the same time every day then that will need two time signals, one for TAI and a new one for earth rotation time. Same problem for anything to do with sun rises/falls and tides (though obviously the precision may not be an issue for some years).
If you want to read more then this article covers the arguments quite well, though biased like me against the idea: http://www.bloomberg.com/news/2011-12-22/un-vote-could-allow-mankind-to-cont...
I'm not sure if NZ has a position on this, but I am trying to find out.
cheers Jay
PS A reminder about our free NTP service, details at: www.ntp.net.nz PPS If you think this is off-topic for this list then please let me know!
-- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840
_______________________________________________ NZNOG mailing list NZNOG(a)list.waikato.ac.nz http://list.waikato.ac.nz/mailman/listinfo/nznog
-- Lindsay Druett. lindsay(a)wired.net.nz +64-7-974 9300 +64-21-92 90 92
participants (8)
-
Andrew McMillan -
Brian E Carpenter -
Don Stokes -
Jay Daley -
Lindsay Druett -
Mark Foster -
Richard Naylor -
Volker Kuhlmann