Re: F-ckin Leap Seconds, how do they work?
http://www.sciencedaily.com/releases/2012/06/120629142607.htm From: Paul WALL pauldotw...@gmail.com To: NANOG list nanog@nanog.org Sent: Saturday, June 30, 2012 6:16 PM Subject: F-ckin Leap Seconds, how do they work? Comments? Drive Slow Paul
Re: F-ckin Leap Seconds, how do they work?
On Wed, 2012-07-04 at 20:48 -0700, Owen DeLong wrote: Given that we don't seem to be able to eliminate the absurdity of DST, I doubt that either of those proposals is likely to fly. Russian govt. did eliminate DST. http://www.rt.com/news/daylight-saving-time-abolished/ --vadim
Re: F-ckin Leap Seconds, how do they work?
On Jul 5, 2012, at 1:35 PM, Vadim Antonov wrote: On Wed, 2012-07-04 at 20:48 -0700, Owen DeLong wrote: Given that we don't seem to be able to eliminate the absurdity of DST, I doubt that either of those proposals is likely to fly. Russian govt. did eliminate DST. http://www.rt.com/news/daylight-saving-time-abolished/ :) http://themoscownews.com/vote/20120629/189902272-results.html --vadim
Re: F-ckin Leap Seconds, how do they work?
On Thu, 2012-07-05 at 14:00 +0400, Dmitry Burkov wrote: On Jul 5, 2012, at 1:35 PM, Vadim Antonov wrote: On Wed, 2012-07-04 at 20:48 -0700, Owen DeLong wrote: Given that we don't seem to be able to eliminate the absurdity of DST, I doubt that either of those proposals is likely to fly. Russian govt. did eliminate DST. http://www.rt.com/news/daylight-saving-time-abolished/ :) http://themoscownews.com/vote/20120629/189902272-results.html 75.9% of people are dimwits :) --vadim
Re: F-ckin Leap Seconds, how do they work?
On Wed, Jul 04, 2012 at 06:10:45PM -0400, William Herrin wrote: IMO, leap seconds are a really bad idea. Let the vanishingly few people who care about a precision match against the solar day keep track of the deviation from clock time and let everybody else have a *simple* clock year after year. When the deviation increases to an hour every what, thousand years? Then you can do a big, well publicized correction where everybody is paying attention to making it work instead of being caught by surprise. Notice that already InterplaNet requires a time base not linked to a particular planetary body. If we're looking at kiloyear scales, then either nobody will care about celestial dynamics of a particular planetary body, or nobody will care about precise time standards any longer.
Re: F-ckin Leap Seconds, how do they work?
Live further north and you will see the difference dst makes. On Jul 4, 2012, at 11:48 PM, Owen DeLong o...@delong.com wrote: Given that we don't seem to be able to eliminate the absurdity of DST, I doubt that either of those proposals is likely to fly.
Re: F-ckin Leap Seconds, how do they work?
On 05/07/2012 11:34, Jared Mauch wrote: Live further north and you will see the difference dst makes. This is true. Ireland, UK, NL, Denmark, northern Germany and northern Poland are at a similar latitude to Polar Bear Provincial Park by Hudson Bay. With DST, we get much more usable evenings March through October, and the sun rises at 05:00 instead of 04:00 in the morning, so early risers don't get woken up at 4 every day. During the winter, regular time means that we have sunrise after 08:30 for 5 weeks. At this latitude, DST is serious win. Nick
Re: F-ckin Leap Seconds, how do they work?
On 05/07/12 13:05, Nick Hilliard wrote: On 05/07/2012 11:34, Jared Mauch wrote: Live further north and you will see the difference dst makes. This is true. Ireland, UK, NL, Denmark, northern Germany and northern Poland are at a similar latitude to Polar Bear Provincial Park by Hudson Bay. With DST, we get much more usable evenings March through October, and the sun rises at 05:00 instead of 04:00 in the morning, so early risers don't get woken up at 4 every day. During the winter, regular time means that we have sunrise after 08:30 for 5 weeks. At this latitude, DST is serious win. Nick Live further north and you will see the absurdity of dst. :) I live in Norway. In summer the sun is up, in winter the sun is not up. At this latitude, dst is..meh. Henning
Re: F-ckin Leap Seconds, how do they work?
On Jul 5, 2012, at 7:18 AM, Henning Stener h.ste...@sportradar.com wrote: On 05/07/12 13:05, Nick Hilliard wrote: On 05/07/2012 11:34, Jared Mauch wrote: Live further north and you will see the difference dst makes. This is true. Ireland, UK, NL, Denmark, northern Germany and northern Poland are at a similar latitude to Polar Bear Provincial Park by Hudson Bay. With DST, we get much more usable evenings March through October, and the sun rises at 05:00 instead of 04:00 in the morning, so early risers don't get woken up at 4 every day. During the winter, regular time means that we have sunrise after 08:30 for 5 weeks. At this latitude, DST is serious win. Nick Live further north and you will see the absurdity of dst. :) I live in Norway. In summer the sun is up, in winter the sun is not up. At this latitude, dst is..meh. I'm only at (aproxamately) 42.28755874876601 north. Once you go near 60 north the value changes significantly. There is a band of latitudes where it does make more sense.
Re: F-ckin Leap Seconds, how do they work?
I'm only at (aproxamately) 42.28755874876601 north. Once you go near 60 north the value changes significantly. There is a band of latitudes where it does make more sense. It sure isn't Indiana. http://thinkprogress.org/climate/2010/03/13/205642/daylight-saving-time-energy-dst/?mobile=nc On 07/05/2012 07:25 AM, Jared Mauch wrote: On Jul 5, 2012, at 7:18 AM, Henning Stener h.ste...@sportradar.com wrote: On 05/07/12 13:05, Nick Hilliard wrote: On 05/07/2012 11:34, Jared Mauch wrote: Live further north and you will see the difference dst makes. This is true. Ireland, UK, NL, Denmark, northern Germany and northern Poland are at a similar latitude to Polar Bear Provincial Park by Hudson Bay. With DST, we get much more usable evenings March through October, and the sun rises at 05:00 instead of 04:00 in the morning, so early risers don't get woken up at 4 every day. During the winter, regular time means that we have sunrise after 08:30 for 5 weeks. At this latitude, DST is serious win. Nick Live further north and you will see the absurdity of dst. :) I live in Norway. In summer the sun is up, in winter the sun is not up. At this latitude, dst is..meh. I'm only at (aproxamately) 42.28755874876601 north. Once you go near 60 north the value changes significantly. There is a band of latitudes where it does make more sense.
Re: F-ckin Leap Seconds, how do they work?
If you want to run a Google-patched NTP server and talk to it, you're welcome to. The rest of us would prefer to just get it right, so we don't have to get lied to. The timescale implementation in NTP is correct accoring to how UTC is defined. I suggest leaving it alone, chances of improving on this part over what Mills has done in half a lifetime is slim. (For those who want to state more incorrect things on this matter, let me just point out that Dave Mills received the PTTI award 2006, so NTP's implementioon of time has sufficient peer review of people who defined how UTC/TAI works.. ) The time format has a best_before date like Unix, so it will require outside information to tell what modulos of time we are in after it runs out of bits. At the IETF TICTOC BOF (a long time ago, and no_one payed attention, as we where being DOSed by the 1588 and mobile people) it was suggested to make a timescale represenation that would be future prof and work on places where time has a different rate compared to earth at sea level. -Peter
Re: F-ckin Leap Seconds, how do they work?
On one of my BSD boxes. /usr/src/share/zoneinfo/leapseconds, I see no - No, but they're allowed; see Figure 9 of RFC 5905: Steve, I commented that it was stated that we where doing both positive and negative corrections. Only positive corrections have been made, and yes, negative are possible. I pointed out in a previous post that we can count 57, 58, 00 or 57, 58, 59, 00 or 57, 58, 59, 60, 00. And actually, this is the only thing operating-systems and applications need to be capable to handle to make it a non_issue. LI Leap Indicator (leap): 2-bit integer warning of an impending leap second to be inserted or deleted in the last minute of the current month with values defined in Figure 9. +---++ | Value | Meaning| +---++ | 0 | no warning | | 1 | last minute of the day has 61 seconds | | 2 | last minute of the day has 59 seconds | | 3 | unknown (clock unsynchronized) | +---++ That's NTP packet format, used to implemment NTP's represenation of UTC, but not the definition of UTC... (What do I do if I receive a packet with 3.) Or better, all the UTC(k) are free-running and the (old) recomenadtion was to try to keep them within 1us, is that unsyncronized -:) And ooops, I did not catch that before, should it not say last minute of the month? If I remember right the posix standard don't allow 60 in seconds... -Peter
RE: F-ckin Leap Seconds, how do they work?
Leap seconds are to align the artificial and very stable atomic timescale with the irregular and slowing rotation of the earth. You are assuming facts not in evidence. The rotation is merely irregular w= ithin the capabilities of our scheme of measurement, calculation, and obser= vation. Once upon a time eclipses of the sun and moon were random magic,= before the mechanism was understood. So to the periodic cycles of the rot= ation of the earth about its axis, the planet about the sun, etc., are view= ed as magical. This is not due to magic, but rather limitations of under= standing. Earth is 10e-8 in frequency, a nanosecond a day is kindof 10e-14 on frequency. Tom has done the work to document it.. http://www.leapsecond.com/museum/earth/ --Peter
Re: F-ckin Leap Seconds, how do they work?
On Thu, Jul 5, 2012 at 9:55 AM, Peter Lothberg r...@stupi.se wrote: Leap seconds are to align the artificial and very stable atomic timescale with the irregular and slowing rotation of the earth. You are assuming facts not in evidence. The rotation is merely irregular w= ithin the capabilities of our scheme of measurement, calculation, and obser= vation. Once upon a time eclipses of the sun and moon were random magic,= before the mechanism was understood. So to the periodic cycles of the rot= ation of the earth about its axis, the planet about the sun, etc., are view= ed as magical. This is not due to magic, but rather limitations of under= standing. Earth is 10e-8 in frequency, a nanosecond a day is kindof 10e-14 on frequency. Tom has done the work to document it.. http://www.leapsecond.com/museum/earth/ And, by the way, the deformations and exchanges of angular momentum that drive Earth rotation variations are probably the best understood global geophysical processes there are. Absolutely no magic is required. Regards Marshall --Peter
Re: F-ckin Leap Seconds, how do they work?
On Jul 5, 2012, at 10:49 48AM, Peter Lothberg wrote: On one of my BSD boxes. /usr/src/share/zoneinfo/leapseconds, I see no - No, but they're allowed; see Figure 9 of RFC 5905: Steve, I commented that it was stated that we where doing both positive and negative corrections. Only positive corrections have been made, and yes, negative are possible. I pointed out in a previous post that we can count 57, 58, 00 or 57, 58, 59, 00 or 57, 58, 59, 60, 00. And actually, this is the only thing operating-systems and applications need to be capable to handle to make it a non_issue. Fair enough. LI Leap Indicator (leap): 2-bit integer warning of an impending leap second to be inserted or deleted in the last minute of the current month with values defined in Figure 9. +---++ | Value | Meaning| +---++ | 0 | no warning | | 1 | last minute of the day has 61 seconds | | 2 | last minute of the day has 59 seconds | | 3 | unknown (clock unsynchronized) | +---++ That's NTP packet format, used to implemment NTP's represenation of UTC, but not the definition of UTC... (What do I do if I receive a packet with 3.) Or better, all the UTC(k) are free-running and the (old) recomenadtion was to try to keep them within 1us, is that unsyncronized -:) And ooops, I did not catch that before, should it not say last minute of the month? The text as I copied it is certainly not consistent... If I remember right the posix standard don't allow 60 in seconds... -Peter --Steve Bellovin, https://www.cs.columbia.edu/~smb
Re: F-ckin Leap Seconds, how do they work?
Most systems that deals with time has a slightly different way of doing it than U*ix.. ref: CCIR 457-1 Like this: 56113.6294791667 56113.6301736111 56113 is MJD, modified julian date (http://tycho.usno.navy.mil/mjd.html) Want to knew the time between two observations, just subtract and you get days and fraction of day. (I's about 60sec between the lines above..) --P Ps: Tops20/Twenex/Tenex keeps the kernel time this way, in 18+18 bits... On 7/3/12, Vadim Antonov a...@kotovnik.com wrote: There's always a possibility of using pseudo-TAI internally by reconstructing it from UTC. This is not the best solution (because it requires systems to have long-term memory of past leap seconds, or How about, instead of requiring systems to remember past leap seconds; You represent every single timestamp instead of as timestamp = 32-bit int, seconds since jan 1 1970 00:00:00 You represent all system timestamps as tuples: timestamp = ( 32-bint int seconds since jan 1 1970 00:00:00, integer representing the leap-second offset since jan 1 1970 ) No need to retain a history. Just retain the data in the same way that Hours, Minutes, and Second are retained. Comparison is simple. (Timestamp2 - Offset2) - (Timestamp1 - Offset1) The downside is you can no longer set your system clock by hand, because humans won't know the right number of leap seconds to supply when setting the time from their wall clock. That's a problem necesitating you keep a history anyways. For time to be universally coordinated, it has to be coordinated. One of the basic requirements for system time is that it interacts with humans, and humans have to be able to set their clock from conventional time sources which are based on local time, without the machine having to be constantly updated or reach out on a network and figure out how that translates into a reasonable machine time. -- -JH
Re: F-ckin Leap Seconds, how do they work?
On Tue, Jul 3, 2012 at 11:59 PM, Majdi S. Abbas m...@latt.net wrote: On Tue, Jul 03, 2012 at 11:33:35PM -0400, Tyler Haske wrote: 4 years. These things are supposed to be synced to a NTP source anyway. Easiest solution is just remove leap second functionality from mainline code, and make it something you have to special-compile for. Please reconcile these two statements. Thanks, --msa Someone running an NTP Server connected to a cesium clock could run the leap-second time code. Since its *their job* to have the correct time, they can do all the fancy rarely used things that make parts of the Internet die every couple of years. A cesium clock don't knew it should do leap seconds unless you tell it, and it only affects the display and the internal time of the clock.. -:) The S1 NTP server and it's host OS has to be told to set the leap-second indicator by hand to.. But all the system on the internet has to knew what to do with this information. In the case of a host_os that do not knew about leap-seconds, NTP will have the correct time and then try to stear the host as fast as it can to loose/gain a second.. -P
Re: F-ckin Leap Seconds, how do they work?
Rather than discussing the pros and cons of UTC and leap seconds, just create your own time system. You could call it OpenTime. OpenTime will use NTP servers where the Stratum 1 servers are synced to some time standard that doesn't care about leap seconds. That way the consumer can chose to connect his machines to UTC or OpenTime. And what do you do if OpenTime and UTC differs so that it matters? Do the fligt leave at 1200 UTC or 1200 OpenTime? Most countries have a law that says something like measurement is to be traceable to a national standard for legal and trade use. (weight, mass, volume, current, time ...). For those who don't knew, none of the national labs that have local representation of UTC have the EXACT same time. So if there is a dispute you need to be able to show traceability to YOUR national lab. -P
Re: F-ckin Leap Seconds, how do they work?
I'm only at (aproxamately) 42.28755874876601 north. Once you go near 60 north the value changes significantly. There is a band of latitudes where it does make more sense. Why punish the rest of us to accommodate a few people who live between about 50º and 55º latitude? Owen
Re: F-ckin Leap Seconds, how do they work?
On Thu, Jul 05, 2012 at 09:33:05AM -0700, Owen DeLong wrote: I'm only at (aproxamately) 42.28755874876601 north. Once you go near 60 north the value changes significantly. There is a band of latitudes where it does make more sense. Why punish the rest of us to accommodate a few people who live between about 50º and 55º latitude? (easier typing with a real keyboard)... This is a local/states rights issue imho :) AZ ignores DST and as a result I never know what time it is there ;) This is a local state-by-state and county-by-county issue as evidenced by the behavior of counties in Indiana that are close to or within the Chicago MSA. This is more a social issue than anything else. Many people prefer some daylight when they are not working. - Jared -- Jared Mauch | pgp key available via finger from ja...@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: F-ckin Leap Seconds, how do they work?
On Wed, Jul 4, 2012 at 17:22 UTC, Scott Howard wrote: On Wed, Jul 4, 2012 at 8:50 AM, Jimmy Hess mysi...@gmail.com wrote: The NTP daemon could still provide a configuration option to not implement leap-seconds locally, or ignore the leap-second announcement received. So the admin can make a tradeoff favoring Stability over Correctness, of _allowing_ the local clock to become 1 second inaccurate for a short time after the rare occasion of a leap second; and step it or slew the local clock, eg include the leap second in the ordinary time correction, averaged over a period of time instead of a 1 second jump. Unless I'm mis-reading things, it already does - of sorts. I hope anyone implementing systems that depend on minutae of leap seconds does not rely solely on your reading, but actually tests by inconveniently setting their clock and ntpd leapfile to actually insert a leap second. According to the ntpd website ( http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm#AEN2499) : That FAQ is woefully out of date. http://support.ntp.org/ has more current information. The best reference for a given ntpd version is the html docs included in the tarball for that version. Some widely-used versions' html documentation is archived at http://doc.ntp.org/ *The theory of leap seconds in explained in Q: 2.4.. In reality there are two cases to consider: If the operating system implements the kernel discipline described in Section 5.2, ntpd will announce insertion and deletion of leap seconds to the kernel. The kernel will handle the leap seconds without further action necessary. But exactly how it handles it is up to the kernel. Linux and FreeBSD essentially step the clock backward 1s at 23:59:60.0 UTC. At least one system (I believe it was NetBSD or OpenBSD) instead stalls the clock for 1s, though each reading of the clock during that period is greater than the prior, the delta is microscopic and not related to elapsed time within that second, but simply preserves ordering of events. Dr. Mills attempted to exhort kernel developers to implement leap seconds while keeping the system time ever-increasing, but that advice was largely ignored because of implementation difficulty. For example, when first considered, NTP kernel extensions had microsecond precision. The approach of adding a tiny amount with each reading would open the system up to problems if apps could read the clock more than 1 million times during the leap second. It's also ugly for a SMP kernel to maintain global state on the last clock reading across processors. Most systems offer a monotonic alternative to the wall clock, typically implemented as an uptime counter in nominal SI seconds (nominal as defined by hardware, as the monotonic clock is _not_ disciplined by ntpd or affected by steps (setting the wall clock to a particular value). Look for CLOCK_MONOTONIC in the documentation of clock_gettime. There are also interval-only timer facilities like timer_settime. The tools are at hand for those who understand the implications of clock steps (which can occur under circumstances other than leap seconds). If the operating system does not implement the kernel discipline, the clock will show an error of one second relative to NTP's time immediate after the leap second. The situation will be handled just like an unexpected change of time: The operating system will continue with the wrong time for some time, but eventually ntpd will step the time. Effectively this will cause the correction for leap seconds to be applied too late. * This is the historic behavior of ntpd, but after years of complaints, it was changed. ntpd 4.2.6 and later step the clock backward 1s at the scheduled insertion if using the daemon loop discipline (as opposed to the kernel loop discipline). Linux does implement the kernel discipline (via ntp_adjtime), so the first option is what normally happens. However you can disable this with an ntpd config option (disable kernel) or via ntpdc at which point I'm presuming it will fall back to the second option. The second option still gives you a step, but using the -x option to NTPD will slew this step, giving a gradual correction to the 1 second difference. That is incorrect. -x is often misunderstood -- it does not disable stepping entirely, it raises the step threshold from 0.128s default to 600s. When ntpd synchronizes the clock and determines the offset exceeds the step threshold, the clock is stepped to the correct time. So long as you manage to keep your clock within 10 minutes of correct, -x isn't terribly different from disabling steps, but that's not what it does. In particular, when ntpd using the daemon loop implements a leap second by stepping the clock backward one second, the step threshold (and hence -x) are not a decision factor -- the step is taken. Cheers, Dave Hart
Re: F-ckin Leap Seconds, how do they work?
On 7/5/2012 5:54 PM, Peter Lothberg wrote: Rather than discussing the pros and cons of UTC and leap seconds, just create your own time system. You could call it OpenTime. OpenTime will use NTP servers where the Stratum 1 servers are synced to some time standard that doesn't care about leap seconds. That way the consumer can chose to connect his machines to UTC or OpenTime. And what do you do if OpenTime and UTC differs so that it matters? Do the fligt leave at 1200 UTC or 1200 OpenTime? ... Lets see. There have been nine leap seconds in 20 years. So at the start of the next century the difference will probably be less than a minute Remember OpenTime is only for people who want their system clocks to ignore leap seconds. I don't include myself among the possible users of OpenTime.
Re: F-ckin Leap Seconds, how do they work?
On Thu 2012-07-05T10:26:22 -0700, Roy hath writ: Lets see. There have been nine leap seconds in 20 years. So at the start of the next century the difference will probably be less than a minute There is no predicting how large the decadal variations in LOD will be, but the difference should be somewhere between 1 minute and 3 minutes. Please see these charts and tables for how unpredictable it is. http://www.ucolick.org/~sla/leapsecs/dutc.html Remember OpenTime is only for people who want their system clocks to ignore leap seconds. I don't include myself among the possible users of OpenTime. Anyone who needs that can already do that using existing, deployed, and tested code and hardware and the GPS system time scale. Please see this worked example. Please do not invent yet another private time scale. http://www.ucolick.org/~sla/leapsecs/right+gps.html -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
Re: F-ckin Leap Seconds, how do they work?
On Jul 5, 2012, at 10:07 AM, Jared Mauch wrote: On Thu, Jul 05, 2012 at 09:33:05AM -0700, Owen DeLong wrote: I'm only at (aproxamately) 42.28755874876601 north. Once you go near 60 north the value changes significantly. There is a band of latitudes where it does make more sense. Why punish the rest of us to accommodate a few people who live between about 50º and 55º latitude? (easier typing with a real keyboard)... This is a local/states rights issue imho :) AZ ignores DST and as a result I never know what time it is there ;) This is a local state-by-state and county-by-county issue as evidenced by the behavior of counties in Indiana that are close to or within the Chicago MSA. This is more a social issue than anything else. Many people prefer some daylight when they are not working. As do I... Which, if we simply go with PDT all year long, I'd basically have most of the year. I don't get that with standard time during winter anyway and PDT wouldn't help with that. Daylight time does not add length to the daylight period of the day, it merely reduces the time between wake-up and daylight for some portion of winter time. (Standard time has become the anomaly with daylight savings time being practiced for nearly 8 months each year now). I'm fine with leaving all the clocks permanently on daylight time. Just get rid of the twice-a-year timezone shift. I don't care what timezone we pick, just pick one and stick with it. Owen
Re: F-ckin Leap Seconds, how do they work?
On Jul 5, 2012, at 8:14 AM, Marshall Eubanks marshall.euba...@gmail.com wrote: And, by the way, the deformations and exchanges of angular momentum that drive Earth rotation variations are probably the best understood global geophysical processes there are. Absolutely no magic is required. Not the tectonic ones. The deeper geophysical ones yes, but tectonics is irregular. We understand the underlying plate segment motions well but they express very irregularly over year-decade scales. George William Herbert Sent from my iPhone
Re: F-ckin Leap Seconds, how do they work?
On 7/5/2012 10:42 AM, Steve Allen wrote: On Thu 2012-07-05T10:26:22 -0700, Roy hath writ: Lets see. There have been nine leap seconds in 20 years. So at the start of the next century the difference will probably be less than a minute There is no predicting how large the decadal variations in LOD will be, but the difference should be somewhere between 1 minute and 3 minutes. Please see these charts and tables for how unpredictable it is. http://www.ucolick.org/~sla/leapsecs/dutc.html Remember OpenTime is only for people who want their system clocks to ignore leap seconds. I don't include myself among the possible users of OpenTime. Anyone who needs that can already do that using existing, deployed, and tested code and hardware and the GPS system time scale. Please see this worked example. Please do not invent yet another private time scale. http://www.ucolick.org/~sla/leapsecs/right+gps.html ... So basically the concept of OpenTime is already implemented. All that's needed is a list of Stratum-1 servers that anyone can use.
Re: F-ckin Leap Seconds, how do they work?
On Thu, Jul 5, 2012 at 2:02 PM, Roy r.engehau...@gmail.com wrote: On 7/5/2012 10:42 AM, Steve Allen wrote: On Thu 2012-07-05T10:26:22 -0700, Roy hath writ: Lets see. There have been nine leap seconds in 20 years. So at the start of the next century the difference will probably be less than a minute There is no predicting how large the decadal variations in LOD will be, but the difference should be somewhere between 1 minute and 3 minutes. Please see these charts and tables for how unpredictable it is. http://www.ucolick.org/~sla/leapsecs/dutc.html Remember OpenTime is only for people who want their system clocks to ignore leap seconds. I don't include myself among the possible users of OpenTime. Anyone who needs that can already do that using existing, deployed, and tested code and hardware and the GPS system time scale. Please see this worked example. Please do not invent yet another private time scale. http://www.ucolick.org/~sla/leapsecs/right+gps.html ... So basically the concept of OpenTime is already implemented. All that's needed is a list of Stratum-1 servers that anyone can use. From the website: - The scheme described in this web page uses a non-standard NTP server and a non-standard set of right zoneinfo files. The hard part is that the zoneinfo files must be hacked for GPS time and recompiled whenever a leap second is announced. Hopefully that recompile happens long before the leap second occurs. In this scheme the kernel does not have to handle the leap second. All of the handling of the leap second happens in the zoneinfo files. This is effectively the same as the bi-annual handling of daylight/summer time transitions. There are no real-time changes. Everything about the changes can be easily tested at any time by any user. Wouldn't an easier way to be separate out the timescales where one is just 84600 seconds a day for the next 100 years, and another can keep accurate time for those that need that kind of accuracy? The POSIX standard can remain unchanged, and time can be monotonic. When the cumulative difference like like 5 minutes, we can have a huge pubic 5 year lead time thing to sync the timescales again. (Kind of like DST, no mater how publicly and how often and how well you tell people, folks will still show up to work late). From the website again: A system whose time_t is set using an NTP server giving GPS time (thus the kernel does not have to handle leap seconds) and which is configured to use the usual zoneinfo files will produce formatted date/time strings which are 15 seconds larger than official time. (The value 15 will increment at each leap second.) According to the developer forums this is the variation that Google has chosen for Android devices. This seems like a good kludge. But a second is an arbitrary measure. We might as well add leap half seconds, or leap tenths of a second. I'd prefer leap minutes, so we can have these kinds of threads about 1/60th of the time :) Not that I don't find this entertaining.
Re: F-ckin Leap Seconds, how do they work?
On Thu, Jul 05, 2012 at 10:26:22AM -0700, Roy wrote: Remember OpenTime is only for people who want their system clocks to ignore leap seconds. I don't include myself among the possible users of OpenTime. Obviously you need a machine time, which is monotonous, high-resolution (you don't need too many bits even if you resolve down to Planck time and gigayears) and works on any planetary body or in space at any speed, and a human time, which is dynamically derived from machine time, using algorithms depending on particular location and occasion. The sooner we can separate the machine time from people time, the better.
Re: F-ckin Leap Seconds, how do they work?
On (2012-07-03 16:53 -0700), Owen DeLong wrote: Sure, but even with that, 99% of it has only a passing 'interesting' effect and then recovers. Inclusive you no longer know order of events based on your logs, and virtually none of your software are logging 60th second. What are only interesting and what can cause with luck (or bad luck) catastrophic failures is guess work, no one is going to review all the code written, and almost all of it assumes monotonic time. Quite. But it is not well known that unixtime travels backwards. In part because it shouldn't actually do so. It should simply chime 59 twice. Chiming 59 twice is traveling backwards. It goes to what ever precision you have between 59 and 00, then it goes back to 59 flat. -- ++ytti
Re: F-ckin Leap Seconds, how do they work?
Tyler Haske tyler.ha...@gmail.com writes: Someone running an NTP Server connected to a cesium clock could run the leap-second time code. Since its *their job* to have the correct time, they can do all the fancy rarely used things that make parts of the Internet die every couple of years. Ah, Tyler, I see the problem here. An NTP server is not like an XML-spitting web server which one consults each and every time one wants to know a piece of data (for instance a stock quote, the weather, or in this case, what time it is). NTP assumes a local clock, and the results of periodic queries to higher-than-or-equal-to-local-stratum servers are used to _discipline_ the local clock, steering it to have minimal error. Local clocks have to be consulted much too frequently (logging, timestamping, etc) for just put it in the cloud to work. You might want to read up on NTP (wikipedia provides a reasonable introduction). cheers, -r
Re: F-ckin Leap Seconds, how do they work?
On 7/4/12, Robert E. Seastrom r...@seastrom.com wrote: [snip] Local clocks have to be consulted much too frequently (logging, timestamping, etc) for just put it in the cloud to work. You might want to read up on NTP (wikipedia provides a reasonable introduction). The NTP daemon could still provide a configuration option to not implement leap-seconds locally, or ignore the leap-second announcement received. So the admin can make a tradeoff favoring Stability over Correctness, of _allowing_ the local clock to become 1 second inaccurate for a short time after the rare occasion of a leap second; and step it or slew the local clock, eg include the leap second in the ordinary time correction, averaged over a period of time instead of a 1 second jump. The breakage doesn't occur for whatever reason when the time is stepped forward or backwards, or slewwed. So accept the inaccuracy and correct the clock in the normal way that NTP corrects clocks that have drifted. -- -JH
Re: F-ckin Leap Seconds, how do they work?
On 2012 Jul 4, at 08:50, Jimmy Hess wrote: So accept the inaccuracy and correct the clock in the normal way that NTP corrects clocks that have drifted. This is basically the leap smear that google instituted after the issues in 2005. It works nicely in cloud applications where real-time is not an issue. It does not work so well when precision calculations of real-time physics are important, nor in heterogeneous environments where not all devices pay attention to NTP or some handle the leap differently than others. Those are places where a kernel should never be asked to do what the combination of POSIX and leap seconds demand. -- Steve Allen s...@ucolick.org WGS-84 (GPS) UCO/Lick Observatory Natural Sciences II, Room 165 Lat +36.99855 University of California Voice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064 http://www.ucolick.org/~sla/ Hgt +250 m
Re: F-ckin Leap Seconds, how do they work?
On Wed, Jul 4, 2012 at 8:50 AM, Jimmy Hess mysi...@gmail.com wrote: The NTP daemon could still provide a configuration option to not implement leap-seconds locally, or ignore the leap-second announcement received. So the admin can make a tradeoff favoring Stability over Correctness, of _allowing_ the local clock to become 1 second inaccurate for a short time after the rare occasion of a leap second; and step it or slew the local clock, eg include the leap second in the ordinary time correction, averaged over a period of time instead of a 1 second jump. Unless I'm mis-reading things, it already does - of sorts. According to the ntpd website ( http://www.ntp.org/ntpfaq/NTP-s-algo-real.htm#AEN2499) : *The theory of leap seconds in explained in Q: 2.4.. In reality there are two cases to consider: If the operating system implements the kernel discipline described in Section 5.2, ntpd will announce insertion and deletion of leap seconds to the kernel. The kernel will handle the leap seconds without further action necessary. If the operating system does not implement the kernel discipline, the clock will show an error of one second relative to NTP's time immediate after the leap second. The situation will be handled just like an unexpected change of time: The operating system will continue with the wrong time for some time, but eventually ntpd will step the time. Effectively this will cause the correction for leap seconds to be applied too late. * Linux does implement the kernel discipline (via ntp_adjtime), so the first option is what normally happens. However you can disable this with an ntpd config option (disable kernel) or via ntpdc at which point I'm presuming it will fall back to the second option. The second option still gives you a step, but using the -x option to NTPD will slew this step, giving a gradual correction to the 1 second difference. Of course there would be side effects of this (the kernel implementation of NTP is there for a reason, and this disables it), but at least it's better than a server hang... Scott.
Re: F-ckin Leap Seconds, how do they work?
On Tue, Jul 03, 2012 at 04:54:24PM -0400, valdis.kletni...@vt.edu wrote: On Tue, 03 Jul 2012 21:49:40, Peter Lothberg said: Leapseconds can be both positive and negative, but up to now, the earth has only slowed down, so we have added seconds. That's what many people believe, but it's not exactly right. Leap seconds are added for the exact same reason leap days are - the earth's rotation isn't a clean multiple of the year. We know we need to stick in an entire leap day every 4 years or so, then add the 400 hack to get it closer. At that point, it's *really* close, to the point where just shimming in a second every once in a while is enough to get it back in sync. The earth's slowdown (or speedup) is measured by *how often* we need to add leap seconds. If we needed to add one every 3 years, but the frequency rises to once every 2.5 years, *that* indicates slowing. In other words, the slowdown or speedup is the first derivative of the rate that UT and TAI diverge - if the earth rotated at constant speed, the derivative would be zero, and we'd insert leap seconds on a nice predictable schedule. Leap Seconds and Leap Years are completely unrelated and solve two completely different problems. Leap Seconds exist to adjust time to match the Earth's actual rotation. They exist because the solar day is not exactly 24 hours. Leap Years exist to adjust time to match the Earth's actual revolution around the Sun. They exist because the that time period isn't exactly 365 days. Without leap seconds, the sun stops being overhead at noon. Without leap years, the equinozes and solstices start drifting to different days. -- Brett
Re: F-ckin Leap Seconds, how do they work?
On Wed, 04 Jul 2012 12:44:40 -0500, Brett Frankenberger said: Leap Seconds and Leap Years are completely unrelated and solve two completely different problems. Leap Seconds exist to adjust time to match the Earth's actual rotation. They exist because the solar day is not exactly 24 hours. Leap Years exist to adjust time to match the Earth's actual revolution around the Sun. They exist because the that time period isn't exactly 365 days. Actually, it's the same exact problem - an astronomical value isn't exactly conformant to the civil value, and thus adjustments are needed. And you missed the bigger point - that leap seconds aren't needed because the earth is slowing any more than leap days are needed because the year is getting longer. If an actual siderial day was a fixed unchanging 86400.005 seconds long, you'd still need a leap second every 200 days. *SLOWING* would be indicated by the every 200 days changing to every 175 or every 150. For bonus points - at the current rate of slowing, in what year will the day be of sufficient length that the current rule of 400 for leap days requires changing? You may assume that the orbital parameters of the Earth do not also change. :) pgpOsreuTOR8f.pgp Description: PGP signature
Re: F-ckin Leap Seconds, how do they work?
On Wed, Jul 4, 2012 at 1:44 PM, Brett Frankenberger rbf+na...@panix.com wrote: Without leap seconds, the sun stops being overhead at noon. But that's ridiculous. The sun *isn't* overhead at noon except at one particular longitude within each time zone. Everywhere else time synch to local noon is +/- half an hour. IMO, leap seconds are a really bad idea. Let the vanishingly few people who care about a precision match against the solar day keep track of the deviation from clock time and let everybody else have a *simple* clock year after year. When the deviation increases to an hour every what, thousand years? Then you can do a big, well publicized correction where everybody is paying attention to making it work instead of being caught by surprise. Regards, Bill Herrin -- William D. Herrin her...@dirtside.com b...@herrin.us 3005 Crane Dr. .. Web: http://bill.herrin.us/ Falls Church, VA 22042-3004
Re: F-ckin Leap Seconds, how do they work?
On Wed, Jul 04, 2012 at 06:10:45PM -0400, William Herrin wrote: On Wed, Jul 4, 2012 at 1:44 PM, Brett Frankenberger rbf+na...@panix.com wrote: Without leap seconds, the sun stops being overhead at noon. But that's ridiculous. The sun *isn't* overhead at noon except at one particular longitude within each time zone. Everywhere else time synch to local noon is +/- half an hour. IMO, leap seconds are a really bad idea. Let the vanishingly few people who care about a precision match against the solar day keep track of the deviation from clock time and let everybody else have a *simple* clock year after year. When the deviation increases to an hour every what, thousand years? Then you can do a big, well publicized correction where everybody is paying attention to making it work instead of being caught by surprise. Yeah but what you don't understand is that manual navigation after a certain point of difference becomes inaccurate to a degree that is unacceptable by most military standards. 100 or a 1000 years the difference is too big. Someone somewhere at some point evaluated this need in the range of 0.3 - 0.9? in order for nauticle and other means of direction to not be impacted. It would be easy to disagree and say Well! we have GPS and other such digital devices to tell where you are now!... and if those go out just like all these failing Java Apps ?. I would not want to be the guy that would have to calculate all possible differences just to attempt to get a accurate location and then find out the math was wrong and you are 100 miles off target. Just sayin! -- - (2^(N-1))
Re: F-ckin Leap Seconds, how do they work?
On Jul 4, 2012, at 3:29 PM, Jason Hellenthal jhellent...@dataix.net wrote: Yeah but what you don't understand is that manual navigation after a certain point of difference becomes inaccurate to a degree that is unacceptable by most military standards. Manual navigation (sextant, etc) is dead. It's not taught for new pilots or mariners / navigators. A few hobbyists still learn that, but they can easily keep a solar-true time clock around if they wish. Maintaining any time standard for that purpose is not supported. It's no reason for the timekeepers, nothing we need to care about. The few navigation systems that look at the sun and stars have - and inherently need - better time reference than the allowed 0.9 sec before we leap. They already handle this internally. That 0.9 sec max error comes to up to about 400 meters for equitorial surface nav or 6500 for orbital objects (or suborbital - cough). Already unacceptable... George William Herbert Sent from my iPhone
Re: F-ckin Leap Seconds, how do they work?
On Wed, Jul 04, 2012 at 05:02:02PM -0400, valdis.kletni...@vt.edu wrote: On Wed, 04 Jul 2012 12:44:40 -0500, Brett Frankenberger said: Leap Seconds and Leap Years are completely unrelated and solve two completely different problems. Leap Seconds exist to adjust time to match the Earth's actual rotation. They exist because the solar day is not exactly 24 hours. Leap Years exist to adjust time to match the Earth's actual revolution around the Sun. They exist because the that time period isn't exactly 365 days. Actually, it's the same exact problem - an astronomical value isn't exactly conformant to the civil value, and thus adjustments are needed. No. Leap Years arise because the solar year is not an integral multiple of the solar day. Yes, you can argue that leap years exist because the Earth doesn't revolve around the sun in 86400*365 seconds, but that missed the underlying point that since well before civil time differed from solar time, people have defined a year in terms of days, preferring not to have years starting a midnight, then dawn, then noon, then dusk, and so on. Leap years have existed since well before civil time and solar time were any different. And you missed the bigger point - that leap seconds aren't needed because the earth is slowing any more than leap days are needed because the year is getting longer. If an actual siderial day was a fixed unchanging 86400.005 seconds long, you'd still need a leap second every 200 days. *SLOWING* would be indicated by the every 200 days changing to every 175 or every 150. I assume you meant solar instead of [sidereal] -- the sidereal day hasn't been 86400.anything seconds ever. And if the mean solar day were unchanging, then it would be 86400 civil seconds today, just like it was (by definition) in 1900. The civil second was initially defined as 1/86400 of the mean solar day in 1900 (then later redefined based on radiation from the cesium atom, but the redefinition didn't change the length of the second by enough to matter for the purposes of this discission). The only reason the mean solar day today isn't 86400 is because the Earth's rotation has slowed since 1900 and we've elected to not redefine the length of a second. Yes, technically, you're right that if the Earth's rotation rate were constant and were such that the mean solar day were 86400.005 seconds long, we'd still need leap sections. But that's a highly unlikely counterfactual hypothetical, because, again, if the Earth weren't slowing, then 1/86400-of-mean-solar-day defintion of the second would still hold. There's virtually no chance that on a hypothetical Earth that wasn't slowing, that population would have decided that the second should be 1/86400.005 of a solar day. -- Brett
Re: F-ckin Leap Seconds, how do they work?
On Wed, 04 Jul 2012 21:01:50 -0500, Brett Frankenberger said: No. Leap Years arise because the solar year is not an integral multiple of the solar day. And leap seconds arise because the astronomical day is not an integral multiple of the hour, minute, or second. Same problem. still hold. There's virtually no chance that on a hypothetical Earth that wasn't slowing, that population would have decided that the second should be 1/86400.005 of a solar day. Look up the *original* definition of the meter, and think about the phrase measurement error. pgp0bwEdWYPVB.pgp Description: PGP signature
Re: F-ckin Leap Seconds, how do they work?
On 7/4/12, William Herrin b...@herrin.us wrote: IMO, leap seconds are a really bad idea. Let the vanishingly few people who care about a precision match against the solar day keep track of the deviation from clock time and let everybody else have a *simple* clock year after year. When the deviation increases to an hour every what, thousand years? Then you can do a big, well publicized correction where everybody is paying attention to making it work instead of being caught by surprise. [snip] Instead of having leap seconds; redraw the world timezone map, so that the boundaries of every time zone are shifted by a distance in feet that corresponds to one second; and such that after a thousand years and an hour's worth of leap seconds, the physical locations of the timezones will have shifted just so far, that there is a 1 hour adjustment. :) -- -JH
Re: F-ckin Leap Seconds, how do they work?
On Jul 4, 2012, at 8:39 PM, Jimmy Hess wrote: On 7/4/12, William Herrin b...@herrin.us wrote: IMO, leap seconds are a really bad idea. Let the vanishingly few people who care about a precision match against the solar day keep track of the deviation from clock time and let everybody else have a *simple* clock year after year. When the deviation increases to an hour every what, thousand years? Then you can do a big, well publicized correction where everybody is paying attention to making it work instead of being caught by surprise. [snip] Instead of having leap seconds; redraw the world timezone map, so that the boundaries of every time zone are shifted by a distance in feet that corresponds to one second; and such that after a thousand years and an hour's worth of leap seconds, the physical locations of the timezones will have shifted just so far, that there is a 1 hour adjustment. :) -- -JH Given that we don't seem to be able to eliminate the absurdity of DST, I doubt that either of those proposals is likely to fly. Owen
Re: F-ckin Leap Seconds, how do they work?
Rather than discussing the pros and cons of UTC and leap seconds, just create your own time system. You could call it OpenTime. OpenTime will use NTP servers where the Stratum 1 servers are synced to some time standard that doesn't care about leap seconds. That way the consumer can chose to connect his machines to UTC or OpenTime.
Re: F-ckin Leap Seconds, how do they work?
On 7/5/2012 12:47 AM, Roy wrote: Rather than discussing the pros and cons of UTC and leap seconds, just create your own time system. You could call it OpenTime. OpenTime will use NTP servers where the Stratum 1 servers are synced to some time standard that doesn't care about leap seconds. That way the consumer can chose to connect his machines to UTC or OpenTime. Oblig: http://xkcd.com/927/ - Pete smime.p7s Description: S/MIME Cryptographic Signature
Re: F-ckin Leap Seconds, how do they work?
On 7/4/2012 10:06 PM, Peter Kristolaitis wrote: On 7/5/2012 12:47 AM, Roy wrote: Rather than discussing the pros and cons of UTC and leap seconds, just create your own time system. You could call it OpenTime. OpenTime will use NTP servers where the Stratum 1 servers are synced to some time standard that doesn't care about leap seconds. That way the consumer can chose to connect his machines to UTC or OpenTime. Oblig: http://xkcd.com/927/ - Pete Right on!
Re: F-ckin Leap Seconds, how do they work?
On 7/4/12 8:48 PM, Owen DeLong wrote: Given that we don't seem to be able to eliminate the absurdity of DST, I doubt that either of those proposals is likely to fly. Owen Before we had timezones your clock offset was forward or backward 4 minutes every-time you crossed a meridian.
Re: F-ckin Leap Seconds, how do they work?
On Mon, Jul 02, 2012 at 09:13:42AM -0700, Michael Thomas wrote: My centos 6/64 running 3.0 seemed to weather it too. I'm not quite clear on what I should be looking for to classify it as being broken though. The problems I saw were related to programs that use futex(2) (Java, MySQL, Chromium, in my personal experience) chewing up lots of CPU because the futex system call wasn't quite doing what it was supposed to be doing (waking up threads when they were OK to proceed) and instead constantly waking the threads up, having the threads go OK, so my lock is clear and I'm ready to go?, the kernel saying oh, no, sorry and the thread going back to sleep again -- only to be woken up again immediately. Sort of an object lesson in why busy-wait locks suck. - Matt -- The main advantages of Haynes and Chilton manuals are that they cost $15, where the factory manuals cost $100 and up, and that they will tell you how to use two hammers, a block of wood, and a meerkat to replace special tool no. 2-112-A-- Matt Roberds in asr.
Re: F-ckin Leap Seconds, how do they work?
+-- | On 2012-07-03 17:27:14, Matthew Palmer wrote: | | The problems I saw were related to programs that use futex(2) (Java, MySQL, | Chromium, in my personal experience) chewing up lots of CPU because the | futex system call wasn't quite doing what it was supposed to be doing | (waking up threads when they were OK to proceed) and instead constantly | waking the threads up, having the threads go OK, so my lock is clear and | I'm ready to go?, the kernel saying oh, no, sorry and the thread going | back to sleep again -- only to be woken up again immediately. Sort of an | object lesson in why busy-wait locks suck. A good dig into the problem, and previous problems with that code: http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.html Cheers. -- bdha cyberpunk is dead. long live cyberpunk.
Re: F-ckin Leap Seconds, how do they work?
Steven Bellovin s...@cs.columbia.edu writes: See http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.html Maybe we should stop wrenching the poor system time back and forth. We no longer add or subtract daylight savings time (or timezones) to the kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and timezones already are. I believe the Olson time code already has ifdefs for doing this. I wonder why the system's internal time isn't run that way. -wolfgang -- g+: https://plus.google.com/114566345864337108516/about
Re: F-ckin Leap Seconds, how do they work?
DST is a time-zone specific phenomenon. Leap seconds are changes to the actual core time. UTC moves with leap seconds. It doesn't move with DST or other timezone weirdnesses. The system clock needs to be UTC, not UTC ± some offset stuck somewhere that keeps some form of running tally of the current leap second offset since the epoch. Owen On Jul 3, 2012, at 1:54 AM, Wolfgang S. Rupprecht wrote: Steven Bellovin s...@cs.columbia.edu writes: See http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.html Maybe we should stop wrenching the poor system time back and forth. We no longer add or subtract daylight savings time (or timezones) to the kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and timezones already are. I believe the Olson time code already has ifdefs for doing this. I wonder why the system's internal time isn't run that way. -wolfgang -- g+: https://plus.google.com/114566345864337108516/about
Re: F-ckin Leap Seconds, how do they work?
On (2012-07-03 01:54 -0700), Wolfgang S. Rupprecht wrote: kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and Yes. TAI time natively and presentation uses leap lookup tables to convert to UTC. Unixtime is not monotonously increasing which is incredibly broken by design. http://en.wikipedia.org/wiki/Unixtime#TAI-based_variant http://cr.yp.to/libtai.html -- ++ytti
Re: F-ckin Leap Seconds, how do they work?
Jimmy Hess mysi...@gmail.com wrote: Someone should write a dastardly system clock daemon to cause the insertion of frequent spurious positive leap seconds, followed by the spurious insertion of negative leap seconds. For testing purposes... any application which crashes under such a test, should be repaired or not used in any critical capacity For testing applications you can try libfaketime. Testing systems is a bit harder... https://github.com/wolfcw/libfaketime Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ FitzRoy, Sole: West or southwest 4 or 5, occasionally 6. Moderate or rough. Occasional rain or drizzle, fog patches. Moderate or good, occasionally very poor.
Re: F-ckin Leap Seconds, how do they work?
Wolfgang S. Rupprecht wolfgang.ruppre...@gmail.com wrote: I wonder why the system's internal time isn't run that way. For compatibility with software that does time calculations without using the crappy libc time API. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Humber, Thames, Dover, Wight: South 4 or 5. Slight or moderate. Occasional rain or drizzle, fog patches. Moderate, occasionally very poor.
Re: F-ckin Leap Seconds, how do they work?
On 7/3/12 01:54 , Wolfgang S. Rupprecht wrote: Steven Bellovin s...@cs.columbia.edu writes: See http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.html Maybe we should stop wrenching the poor system time back and forth. We no longer add or subtract daylight savings time (or timezones) to the kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and timezones already are. I believe the Olson time code already has ifdefs for doing this. I wonder why the system's internal time isn't run that way. Neither timezones nor dst impact length of the mean solar day. TAI is some 35 seconds ahead of UTC this point. and will continue to diverge in a fashion which is not sufficiently predictable that you can know over the long term. Not using utc as the timebase is certainly possible, gps does that for example. Apps are buggy sounds like a really poor excuse for doing so. -wolfgang
Re: F-ckin Leap Seconds, how do they work?
On Tue, 03 Jul 2012 12:31:03 +0300, Saku Ytti said: Yes. TAI time natively and presentation uses leap lookup tables to convert to UTC. On the other hand, how many subtle bugs will we introduce when we break code that currently assumes the system clock is UTC, not TAI? pgpY3qNIz37lt.pgp Description: PGP signature
Re: F-ckin Leap Seconds, how do they work?
On (2012-07-03 10:33 -0400), valdis.kletni...@vt.edu wrote: On the other hand, how many subtle bugs will we introduce when we break code that currently assumes the system clock is UTC, not TAI? Progress has non zero cost :) -- ++ytti
Re: F-ckin Leap Seconds, how do they work?
On Tue, 03 Jul 2012 07:02:33 -0700, Joel jaeggli said: Apps are buggy sounds like a really poor excuse for doing so. When the published API has been the system clock is in UTC for some 3 decades, I hardly think it's acceptable to call apps buggy for assuming that the system clock is in fact using UTC and breaking if you switch it to something that's not UTC. And the new time *has* to have different semantics than UTC, because if it doesn't then what's the point of changing it? pgpuV762Gt9dV.pgp Description: PGP signature
Re: F-ckin Leap Seconds, how do they work?
On 7/3/12 07:51 , valdis.kletni...@vt.edu wrote: On Tue, 03 Jul 2012 07:02:33 -0700, Joel jaeggli said: Apps are buggy sounds like a really poor excuse for doing so. When the published API has been the system clock is in UTC for some 3 decades, I hardly think it's acceptable to call apps buggy for assuming that the system clock is in fact using UTC and breaking if you switch it to something that's not UTC. And the new time *has* to have different semantics than UTC, because if it doesn't then what's the point of changing it? right you and I agree, proposing to switch off UTC becuase of buggy applications is a rather bad premise. software runs into trouble with the handling of leap years. yet few people (apart from perhaps the orthdox church is proposing to throw off the julian and gregorian calender reforms.
Fwd: Re: F-ckin Leap Seconds, how do they work?
-- Forwarded message -- From: shawn wilson ag4ve...@gmail.com Date: Jul 3, 2012 11:33 AM Subject: Re: F-ckin Leap Seconds, how do they work? To: Joel jaeggli joe...@bogus.com I agree with TAI. Epoch is supposed to be an unsigned long int starting ~1970 (there are are 4 epochs iirc, but never mind that). I don't recall the rfc, but I don't recall this spec mentioning leap seconds (and it shouldn't). Frankly our time system is buggy as hell (no year 0, base 60 seconds and minutes, base 24 hours, no standard month base, e/m isn't a part of the system, etc). I find my last issue the most disconcerting with our system and makes it really unreliable - GPS time is *not* earth time and we rely on that skew for everything. To that point, I hate to think how many missile tests it took them to figure that one out :) However there is no reason to add more crap to an already messed up system. On Jul 3, 2012 10:03 AM, Joel jaeggli joe...@bogus.com wrote: On 7/3/12 01:54 , Wolfgang S. Rupprecht wrote: Steven Bellovin s...@cs.columbia.edu writes: See http://landslidecoding.blogspot.com/2012/07/linuxs-leap-second-deadlocks.html Maybe we should stop wrenching the poor system time back and forth. We no longer add or subtract daylight savings time (or timezones) to the kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and timezones already are. I believe the Olson time code already has ifdefs for doing this. I wonder why the system's internal time isn't run that way. Neither timezones nor dst impact length of the mean solar day. TAI is some 35 seconds ahead of UTC this point. and will continue to diverge in a fashion which is not sufficiently predictable that you can know over the long term. Not using utc as the timebase is certainly possible, gps does that for example. Apps are buggy sounds like a really poor excuse for doing so. -wolfgang
Re: Fwd: Re: F-ckin Leap Seconds, how do they work?
On Tue, 03 Jul 2012 11:35:00 -0400, shawn wilson said: and makes it really unreliable - GPS time is *not* earth time and we rely on that skew for everything. To that point, I hate to think how many missile tests it took them to figure that one out :) Actually, GPS time is pretty ugly mathematically, as it has to make relativistic corrections for time dilation due to speed of the satellites and for gravity-well dilation (which are in opposite directions). You don't want to go there in a world where programmers still get the 400 rule for leap years wrong. ;) pgp8kCyHAbnRs.pgp Description: PGP signature
Re: Fwd: Re: F-ckin Leap Seconds, how do they work?
Once upon a time, valdis.kletni...@vt.edu valdis.kletni...@vt.edu said: Actually, GPS time is pretty ugly mathematically, as it has to make relativistic corrections for time dilation due to speed of the satellites and for gravity-well dilation (which are in opposite directions). That's how GPS _calculates_ the time, but GPS time (i.e. time as reported by GPS) is a constant offset from TAI (TAI - UTC as of 1980). -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: F-ckin Leap Seconds, how do they work?
On Jul 3, 2012, at 7:39 AM, Saku Ytti wrote: On (2012-07-03 10:33 -0400), valdis.kletni...@vt.edu wrote: On the other hand, how many subtle bugs will we introduce when we break code that currently assumes the system clock is UTC, not TAI? Progress has non zero cost :) -- ++ytti Trading one known set of bugs for a (probably) larger set of unknown bugs is not my definition of progress. Cost without progress is harmful and should be avoided. Owen
Re: F-ckin Leap Seconds, how do they work?
On (2012-07-03 10:11 -0700), Owen DeLong wrote: Trading one known set of bugs for a (probably) larger set of unknown bugs is not my definition of progress. Cost without progress is harmful and should be avoided. Leap bugs are NOT known. Most people have no idea unixtime is not monotonically increasing. I had no idea myself until sunday, I had assumed we really go 59 - 60 - 00, but we go 59 - 59 - 00. So 59.1 can happen before or after 59.2. To me this is fundamentally and inherently broken. It's quite hard to find code which stores timestamp and then compares it in future to timestamp which assumes time can travel backwards. Most bugs are just things that should last 5s last 6s or 4s, but certainly the bugs exist and developers were not aware that they exist. -- ++ytti
Re: F-ckin Leap Seconds, how do they work?
On 03/07/2012 18:59, Saku Ytti wrote: Leap bugs are NOT known. Most people have no idea unixtime is not monotonically increasing. I had no idea myself until sunday, I had assumed we really go 59 - 60 - 00, but we go 59 - 59 - 00. So 59.1 can happen before or after 59.2. To me this is fundamentally and inherently broken. Well, yeah, it's not obvious that a minute can have anywhere between 59 and 62 seconds. Certainly if POSIX were being redesigned, they ought to consider using libtai. Google's approach to this is interesting: http://googleblog.blogspot.ie/2011/09/time-technology-and-leaping-seconds.html i.e. controlled clock slew until the correct offset is reached, thereby allowing their developers to assume a monotonic system clock. Nick
Re: F-ckin Leap Seconds, how do they work?
On (2012-07-03 19:33 +0100), Nick Hilliard wrote: Google's approach to this is interesting: http://googleblog.blogspot.ie/2011/09/time-technology-and-leaping-seconds.html Yes. I'm sure this is good enough for most people, most people don't need precise time but virtually everyone needs monotonic time. And this is easy to deploy TAI + UTC presentation using leapsecond file lookup isn't exactly easy. Too bad this isn't standard configuration option in NTPd. Also one thing I wonder, why did GOOG choose to skew in just 24h, why not the moment leap is announced? Everyone has some accuracy budget, what ever that might be, it almost certainly is same every day. So you could live with tighter accuracy budget the longer you spend skewing. PC clock on average is probably like 15PPM accurate (or order magnitude of worse, IBM servers seem to be exception). If you'd skew 3 months, your skewing would cause inaccuracy of 0.19PPM. Skewing in single day causes inaccuracy of 11.6PPM (still almost certainly better than free-running PC oscillator) -- ++ytti
RE: F-ckin Leap Seconds, how do they work?
God damn that's a horrid piece of shit web site. You have to disable security and permit remote code execution or it does not work. What a crock! --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org -Original Message- From: Nick Hilliard [mailto:n...@foobar.org] Sent: Tuesday, 03 July, 2012 12:33 To: Saku Ytti Cc: nanog@nanog.org Subject: Re: F-ckin Leap Seconds, how do they work? On 03/07/2012 18:59, Saku Ytti wrote: Leap bugs are NOT known. Most people have no idea unixtime is not monotonically increasing. I had no idea myself until sunday, I had assumed we really go 59 - 60 - 00, but we go 59 - 59 - 00. So 59.1 can happen before or after 59.2. To me this is fundamentally and inherently broken. Well, yeah, it's not obvious that a minute can have anywhere between 59 and 62 seconds. Certainly if POSIX were being redesigned, they ought to consider using libtai. Google's approach to this is interesting: http://googleblog.blogspot.ie/2011/09/time-technology-and-leaping- seconds.html i.e. controlled clock slew until the correct offset is reached, thereby allowing their developers to assume a monotonic system clock. Nick
Re: F-ckin Leap Seconds, how do they work?
- Original Message - From: Wolfgang S. Rupprecht wolfgang.ruppre...@gmail.com Maybe we should stop wrenching the poor system time back and forth. We no longer add or subtract daylight savings time (or timezones) to the kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and timezones already are. I believe the Olson time code already has ifdefs for doing this. I wonder why the system's internal time isn't run that way. I cannot tell you how (literally) shocked I was, to learn from John Stull (at IBM, the first guy, apparently, to locate the current screwup and create kernel patches for it) that *the kernel gets this so wrong*. It's so off that I wasn't sure I was interpreting the situation properly until you posted this. This pain should have been undergone at least 15 years ago; 235960 is a perfectly valid timestamp; ISO8601 says so. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: F-ckin Leap Seconds, how do they work?
- Original Message - From: Owen DeLong o...@delong.com DST is a time-zone specific phenomenon. Nobody said *anything* about DST; that's a complete red herring to discussions of leap seconds. Leap seconds are changes to the actual core time. UTC moves with leap seconds. Correct. The system clock needs to be UTC, not UTC ± some offset stuck somewhere that keeps some form of running tally of the current leap second offset since the epoch. Nope. UTC *includes* leap seconds already. It's UT1 that does not. Are you suggesting that NTP timekeeping should be based on UT1? Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: F-ckin Leap Seconds, how do they work?
- Original Message - From: valdis kletnieks valdis.kletni...@vt.edu When the published API has been the system clock is in UTC for some 3 decades, I hardly think it's acceptable to call apps buggy for assuming that the system clock is in fact using UTC and breaking if you switch it to something that's not UTC. And the new time *has* to have different semantics than UTC, because if it doesn't then what's the point of changing it? Correct. It's very likely that there is *no* sufficiently compelling application requirement that justifies switching NTP from UTC to UT1/TAI. So far as I can tell, the *only* requirement is I need to be able to calculate unixtime-ISO8601 reliably to the second for times further away than the next possible leapsecond; I have not had pointed out to me yet an application which actually requires that; I'm 99 44/100% certain that there isn't one with a sufficiently compelling story to break 3 decades of code. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: F-ckin Leap Seconds, how do they work?
Nick Hilliard n...@foobar.org wrote: Well, yeah, it's not obvious that a minute can have anywhere between 59 and 62 seconds. No a minute cannot have 62 seconds. That is an old documentation bug which has been fixed. http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/time.h.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Viking, North Utsire, South Utsire: Southeasterly 4 or 5, increasing 6 at times. Moderate. Occasional rain, fog patches. Moderate, occasionally very poor.
Re: F-ckin Leap Seconds, how do they work?
Maybe we should stop wrenching the poor system time back and forth. We no longer add or subtract daylight savings time (or timezones) to the kernel time, why do we do it with leapseconds? We should really move the leapseconds correction into the display routines like DST and timezones already are. I believe the Olson time code already has ifdefs for doing this. I wonder why the system's internal time isn't run that way. I cannot tell you how (literally) shocked I was, to learn from John Stull (at IBM, the first guy, apparently, to locate the current screwup and create kernel patches for it) that *the kernel gets this so wrong*. It's so off that I wasn't sure I was interpreting the situation properly until you posted this. This pain should have been undergone at least 15 years ago; 235960 is a perfectly valid timestamp; ISO8601 says so. I leave the computer kernels out of this for a second..:-) We have a timescale that runs at constant speed forward it's named TAI, it is based on the definition on the atomic second. Some systems like GPS have their own idea of a base time and then they have a way of telling the difference between their timescale and UTC. In the case of GPS, they took the numer of leap seconds currently in play when the system was launched and keept that. (as their calendar is 1024 weeks, mosty receivers use the UTC-GPS ofset to figure out what modulo 1024 weeks we are in). TAI is atomic time, UTC(k) is what we use for practical timekeeping, and the problem at hand is that the atomic second runs at constant speed, but the earth is not. Leapseconds can be both positive and negative, but up to now, the earth has only slowed down, so we have added seconds. There are applications on the earth that deals with the earth position in repect to other planets and the sun, so in order to have one timescale for everyone UTC is compensated for the earth rotation speed, when the solar time differs from atomic time with more than 0.94 seconds, we compensate by adding or deleting a second the last minute of the last day of a month, in pratice they have picked new-years and jun/jul. You have all heard GMT, if we don't insert leap seconds as the earth is slowing down GMT will be PMT (paris mean time) in some 65000 years. And day and night will be swapped in 12*65000 years. So in order to avoid having to ask someone gving you a time and date what timescale he/she refers to refered we have UTC, and as all things in life it's a compromize. --Peter Ps: fix your broken code, most systems can handle leap days by now, every 4 years, except years that ends with 00..
Re: F-ckin Leap Seconds, how do they work?
On Jul 3, 2012, at 10:59 AM, Saku Ytti wrote: On (2012-07-03 10:11 -0700), Owen DeLong wrote: Trading one known set of bugs for a (probably) larger set of unknown bugs is not my definition of progress. Cost without progress is harmful and should be avoided. Leap bugs are NOT known. Most people have no idea unixtime is not monotonically increasing. I had no idea myself until sunday, I had assumed we really go 59 - 60 - 00, but we go 59 - 59 - 00. So 59.1 can happen before or after 59.2. To me this is fundamentally and inherently broken. It's quite hard to find code which stores timestamp and then compares it in future to timestamp which assumes time can travel backwards. Most bugs are just things that should last 5s last 6s or 4s, but certainly the bugs exist and developers were not aware that they exist. -- ++ytti If you don't know that time is not monotonically increasing, then that only becomes a software bug when you codify your own ignorance into software you write. It is well known that leap seconds exist. The rotation of the planet does not line up well with the orbit of the planet and neither of these lines up particularly well with the rotation and orbit of the moon. Since we have a long standing tradition of using the orbit of the earth to determine years and the orbit of the moon to divide years into months, we use some fudge-factors on the months to make years and months line up. (12 true months would leave us several days short of a complete orbit at the end of the year and seasons would migrate.) Since we have a tradition of measuring diurnal and other repetitive cycles (days) based on the rotation of the earth, we end up with fudge factors to make that line up with months from time to time. (leap seconds). So it goes. Time is much more complex than many people realize. If you write software where time matters, it is your responsibility to learn about these things. Owen
Re: F-ckin Leap Seconds, how do they work?
And I forgot: They made a mistake and missed their intentions of a solar day year 1900 when defining the atomic second. Off by 2s in 100 years. -p
RE: F-ckin Leap Seconds, how do they work?
The system clock needs to be UTC, not UTC ± some offset stuck somewhere that keeps some form of running tally of the current leap second offset since the epoch. Nope. UTC *includes* leap seconds already. It's UT1 that does not. Are you suggesting that NTP timekeeping should be based on UT1? The system clock should be based on UT1 and should be monotonically increasing since this matches the common concept of time. Calculations done with this value are all based on it being UT1 and using the common notion of UT1 rules. The root cause of the difficulties is that someone decided that the system clock would not maintain wall clock time (UT1) but rather some other timebase and then step that time to keep it in sync with UT1. NTP can keep time in UTC (or anything else) if it wants, but it should discipline the system clock to monotonically increasing UT1. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
Re: F-ckin Leap Seconds, how do they work?
On (2012-07-03 12:46 -0700), Owen DeLong wrote: If you don't know that time is not monotonically increasing, then that only becomes a software bug when you codify your own ignorance into software you write. If only all software could be ordered from you Owen, but in practice this is not possible. Some code will be written less intelligent people. And reviewing any code doing foo = timestamp+offset and if now foo, virtually never expects time to move backwards. UTC doesn't move backwards (it goes 59 - 60 - 00). TAI does not move backwards. Unixtime moves backwards, like spanish inquisition no one expects that. It is well known that leap seconds exist. Quite. But it is not well known that unixtime travels backwards. -- ++ytti
RE: F-ckin Leap Seconds, how do they work?
The system clock needs to be UTC, not UTC =C2=B1 some offset stuck somewhere that keeps some form of running tally of the current leap second offset since the epoch. Nope. UTC *includes* leap seconds already. It's UT1 that does not. Are you suggesting that NTP timekeeping should be based on UT1? The system clock should be based on UT1 and should be monotonically increas= ing since this matches the common concept of time. Calculations done with = this value are all based on it being UT1 and using the common notion of U= T1 rules. The root cause of the difficulties is that someone decided that = the system clock would not maintain wall clock time (UT1) but rather some= other timebase and then step that time to keep it in sync with UT1. NTP can keep time in UTC (or anything else) if it wants, but it should disc= ipline the system clock to monotonically increasing UT1. UTC is the universal time. UT1 is astronomical time. As the definition of a atomic second is 9192631770 complete oscillations of cesium 133 between enery level 3 and 4, everyone can make a second in their lab, that's TAI. Just add the lepsecond ofset and you have UTC. UT1-UTC is done by observations from radio astronomers VLBI telecopes and a comitee, you can't make one in your lab, and it's not real time. --P (The only SI metric you can't make is a kilogram, you have to have one of the 28 kilos in the world..)
Re: F-ckin Leap Seconds, how do they work?
UTC doesn't move backwards (it goes 59 - 60 - 00) or 58 - 00 --P
Re: F-ckin Leap Seconds, how do they work?
- Original Message - From: Keith Medcalf kmedc...@dessus.com Are you suggesting that NTP timekeeping should be based on UT1? The system clock should be based on UT1 and should be monotonically increasing since this matches the common concept of time. Calculations done with this value are all based on it being UT1 and using the common notion of UT1 rules. The root cause of the difficulties is that someone decided that the system clock would not maintain wall clock time (UT1) but rather some other timebase and then step that time to keep it in sync with UT1. UTC is monotonic, and is based on UT1. Just not deterministically. :-) The root cause *is* that someone made a bad decision about kernel timekeeping, but it wasn't the choice of timescale. Non-monotonic time is not a feature of UTC *either*. NTP can keep time in UTC (or anything else) if it wants, but it should discipline the system clock to monotonically increasing UT1. As I undertstand it, the problem is not how NTP disciplined the kernel, it's what the kernel does itself. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: F-ckin Leap Seconds, how do they work?
(source http://physics.nist.gov/cuu/Units/second.html ) Unit of time (second) Abbreviations: CGPM, CIPM, BIPM The unit of time, the second, was defined originally as the fraction 1/86 400 of the mean solar day. The exact definition of mean solar day was left to astronomical theories. However, measurement showed that irregularities in the rotation of the Earth could not be taken into account by the theory and have the effect that this definition does not allow the required accuracy to be achieved. In order to define the unit of time more precisely, the 11th CGPM (1960) adopted a definition given by the International Astronomical Union which was based on the tropical year. Experimental work had, however, already shown that an atomic standard of time-interval, based on a transition between two energy levels of an atom or a molecule, could be realized and reproduced much more precisely. Considering that a very precise definition of the unit of time is indispensable for the International System, the 13th CGPM (1967) decided to replace the definition of the second by the following (affirmed by the CIPM in 1997 that this definition refers to a cesium atom in its ground state at a temperature of 0 K): The second is the duration of 9 192 631 770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the cesium 133 atom. If anyone still thinks UT1; We have a NTP server on Earth (say Washington-DC) and Vint has extended the Internet to planet Mars, can we use NTP? (Hints: Looking at the clock on Earth from Mars, you se a satellite with a orbit, gravity changes by other plaets, unknown distance, unknown orbits and time runs faster on mars than on earth..) --P
Re: F-ckin Leap Seconds, how do they work?
On Tue, Jul 03, 2012 at 09:49:40PM +0200, Peter Lothberg wrote: I leave the computer kernels out of this for a second..:-) We have a timescale that runs at constant speed forward it's named TAI, it is based on the definition on the atomic second. Notice that in inertial frame dragging context it's provably impossible to synchronize oscillators. Luckily, Earth has negligible frame dragging, for the kind of accuracy we currently need. For operative values of time lunaticism, there's always http://www.leapsecond.com/time-nuts.htm
Re: F-ckin Leap Seconds, how do they work?
In a message written on Tue, Jul 03, 2012 at 10:47:52PM +0200, Eugen Leitl wrote: Notice that in inertial frame dragging context it's provably impossible to synchronize oscillators. Luckily, Earth has negligible frame dragging, for the kind of accuracy we currently need. I think everyone on this list is going in the wrong direction with this issue. What you're all arguing over is the correct time for some defintion of correct. I'm a bit more practical. How about we write software so a leap second doesn't crash everything? We can then allow the time nuts get back to arguing which leap seconds we should use, or time reference, or whatever. I'd even take off by a second but didn't crash, over crashed. -- Leo Bicknell - bickn...@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ pgp3RLdVofLej.pgp Description: PGP signature
Re: F-ckin Leap Seconds, how do they work?
On Tue, 03 Jul 2012 21:49:40, Peter Lothberg said: Leapseconds can be both positive and negative, but up to now, the earth has only slowed down, so we have added seconds. That's what many people believe, but it's not exactly right. Leap seconds are added for the exact same reason leap days are - the earth's rotation isn't a clean multiple of the year. We know we need to stick in an entire leap day every 4 years or so, then add the 400 hack to get it closer. At that point, it's *really* close, to the point where just shimming in a second every once in a while is enough to get it back in sync. The earth's slowdown (or speedup) is measured by *how often* we need to add leap seconds. If we needed to add one every 3 years, but the frequency rises to once every 2.5 years, *that* indicates slowing. In other words, the slowdown or speedup is the first derivative of the rate that UT and TAI diverge - if the earth rotated at constant speed, the derivative would be zero, and we'd insert leap seconds on a nice predictable schedule. pgp6b4cpwmjYa.pgp Description: PGP signature
Re: F-ckin Leap Seconds, how do they work?
UTC and time is defined as part of the SI system and ITU etc, so we just need to implement the time system correct. If you try to invent your own way, there are surprises we don;t need to re-explore.. On Tue, 03 Jul 2012 21:49:40, Peter Lothberg said: Leapseconds can be both positive and negative, but up to now, the earth has only slowed down, so we have added seconds. That's what many people believe, but it's not exactly right. Leap seconds are added for the exact same reason leap days are - the earth's rotation isn't a clean multiple of the year. We know we need to stick in an entire leap day every 4 years or so, then add the 400 hack to get it closer. At that point, it's *really* close, to the point where just shimming in a second every once in a while is enough to get it back in sync. The earth's slowdown (or speedup) is measured by *how often* we need to add leap seconds. If we needed to add one every 3 years, but the frequency rises to once every 2.5 years, *that* indicates slowing. In other words, the slowdown or speedup is the first derivative of the rate that UT and TAI diverge - if the earth rotated at constant speed, the derivative would be zero, and we'd insert leap seconds on a nice predictable schedule. I'm not an astronomer, but some of the errors we have in the second intenmtion ended up in the earth position measurements, so the table is not nicely spaced.. On one of my BSD boxes. /usr/src/share/zoneinfo/leapseconds, I see no - # @(#)leapseconds 7.17 # Allowance for leapseconds added to each timezone file. # The International Earth Rotation Service periodically uses leap seconds # to keep UTC to within 0.9 s of UT1 # (which measures the true angular orientation of the earth in space); see # Terry J Quinn, The BIPM and the accurate measure of time, # Proc IEEE 79, 7 (July 1991), 894-905. # There were no leap seconds before 1972, because the official mechanism # accounting for the discrepancy between atomic time and the earth's rotation # did not exist until the early 1970s. # The correction (+ or -) is made at the given time, so lines # will typically look like: # LeapYEARMON DAY 23:59:60+ R/S # or # LeapYEARMON DAY 23:59:59- R/S # If the leapsecond is Rolling (R) the given time is local time # If the leapsecond is Stationary (S) the given time is UTC # Leap YEARMONTH DAY HH:MM:SSCORRR/S Leap1972Jun 30 23:59:60+ S Leap1972Dec 31 23:59:60+ S Leap1973Dec 31 23:59:60+ S Leap1974Dec 31 23:59:60+ S Leap1975Dec 31 23:59:60+ S Leap1976Dec 31 23:59:60+ S Leap1977Dec 31 23:59:60+ S Leap1978Dec 31 23:59:60+ S Leap1979Dec 31 23:59:60+ S Leap1981Jun 30 23:59:60+ S Leap1982Jun 30 23:59:60+ S Leap1983Jun 30 23:59:60+ S Leap1985Jun 30 23:59:60+ S Leap1987Dec 31 23:59:60+ S Leap1989Dec 31 23:59:60+ S Leap1990Dec 31 23:59:60+ S Leap1992Jun 30 23:59:60+ S Leap1993Jun 30 23:59:60+ S Leap1994Jun 30 23:59:60+ S Leap1995Dec 31 23:59:60+ S Leap1997Jun 30 23:59:60+ S Leap1998Dec 31 23:59:60+ S Leap2005Dec 31 23:59:60+ S Leap2008Dec 31 23:59:60+ S Leap2012Jun 30 23:59:60+ S # INTERNATIONAL EARTH ROTATION AND REFERENCE SYSTEMS SERVICE (IERS) # # SERVICE INTERNATIONAL DE LA ROTATION TERRESTRE ET DES SYSTEMES DE REFERENCE # # SERVICE DE LA ROTATION TERRESTRE # OBSERVATOIRE DE PARIS # 61, Av. de l'Observatoire 75014 PARIS (France) # Tel. : 33 (0) 1 40 51 22 26 # FAX : 33 (0) 1 40 51 22 91 # Internet : services.i...@obspm.fr
Re: F-ckin Leap Seconds, how do they work?
- Original Message - From: Leo Bicknell bickn...@ufp.org I'd even take off by a second but didn't crash, over crashed. You would, but lots of people would not, and that's not the contract made by the API definition. If you want to run a Google-patched NTP server and talk to it, you're welcome to. The rest of us would prefer to just get it right, so we don't have to get lied to. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Re: F-ckin Leap Seconds, how do they work?
Owen DeLong o...@delong.com wrote: Since we have a tradition of measuring diurnal and other repetitive cycles (days) based on the rotation of the earth, we end up with fudge factors to make that line up with months from time to time. (leap seconds). That is not what leap seconds are. Leap seconds are to align the artificial and very stable atomic timescale with the irregular and slowing rotation of the earth. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Faeroes, South-east Iceland: Easterly 5 or 6, backing northeasterly 4 or 5. Moderate. Occasional rain, fog patches in Faeroes. Moderate or good, occasionally very poor in Faeroes.
Re: F-ckin Leap Seconds, how do they work?
Peter Lothberg r...@stupi.se wrote: We have a NTP server on Earth (say Washington-DC) and Vint has extended the Internet to planet Mars, can we use NTP? No. http://fanf.livejournal.com/116480.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall: Cyclonic, becoming northerly later, 4 or 5, occasionally 6 in far north. Moderate or rough. Rain or showers. Moderate or good, occasionally poor.
RE: F-ckin Leap Seconds, how do they work?
Peter Lothberg r...@stupi.se wrote: As the definition of a atomic second is 9192631770 complete oscillations of cesium 133 between enery level 3 and 4, everyone can make a second in their lab, that's TAI. No, TAI isn't based on the SI second you realise in your lab. It's the SI second realised on the geoid by a large fleet of clocks. If you are on Mars then TAI isn't based on your SI second, because TAI doesn't tick at a fixed rate relative to local proper time owing to the orbital differences of the two planets. UT1-UTC is done by observations from radio astronomers VLBI telecopes and a comitee, you can't make one in your lab, and it's not real time. You can make quite a good approximation to UT1 with a transit instrument and knowledge of your position. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty, Forth, Tyne, Dogger: Southeasterly 4 or 5. Slight or moderate. Rain or drizzle, fog banks. Moderate or poor, occasionally very poor.
Re: F-ckin Leap Seconds, how do they work?
valdis.kletni...@vt.edu valdis.kletni...@vt.edu wrote: Leap seconds are added for the exact same reason leap days are - the earth's rotation isn't a clean multiple of the year. No leap seconds have nothing to do with years. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Rockall: Cyclonic, becoming northerly later, 4 or 5, occasionally 6 in far north. Moderate or rough. Rain or showers. Moderate or good, occasionally poor.
Re: F-ckin Leap Seconds, how do they work?
Peter Lothberg r...@stupi.se wrote: And I forgot: They made a mistake and missed their intentions of a solar day year 1900 when defining the atomic second. Off by 2s in 100 years. No that is not correct, or at least it's nowhere near as simple as that. The atomic second was matched to the second of ephemeris time, and that was based on Newcomb's tables of the sun, which in effect used the average length of the second from the 1800s. http://ucolick.org/~sla/leapsecs/dutc.html Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Viking, North Utsire, South Utsire: Southeasterly 4 or 5, increasing 6 at times. Moderate. Occasional rain, fog patches. Moderate, occasionally very poor.
Re: F-ckin Leap Seconds, how do they work?
On Jul 3, 2012, at 5:06 PM, Peter Lothberg wrote: On one of my BSD boxes. /usr/src/share/zoneinfo/leapseconds, I see no - No, but they're allowed; see Figure 9 of RFC 5905: LI Leap Indicator (leap): 2-bit integer warning of an impending leap second to be inserted or deleted in the last minute of the current month with values defined in Figure 9. +---++ | Value | Meaning| +---++ | 0 | no warning | | 1 | last minute of the day has 61 seconds | | 2 | last minute of the day has 59 seconds | | 3 | unknown (clock unsynchronized) | +---++ Figure 9: Leap Indicator --Steve Bellovin, https://www.cs.columbia.edu/~smb
RE: F-ckin Leap Seconds, how do they work?
Leap seconds are to align the artificial and very stable atomic timescale with the irregular and slowing rotation of the earth. You are assuming facts not in evidence. The rotation is merely irregular within the capabilities of our scheme of measurement, calculation, and observation. Once upon a time eclipses of the sun and moon were random magic, before the mechanism was understood. So to the periodic cycles of the rotation of the earth about its axis, the planet about the sun, etc., are viewed as magical. This is not due to magic, but rather limitations of understanding. Leap seconds are to align the artifical timescale (which we presently assume, based on facts not in evidence) to be very stable with the simple observation of the equinox and zenith of the sun, on which time reconning is based. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
RE: F-ckin Leap Seconds, how do they work?
Keith Medcalf kmedc...@dessus.com wrote: You are assuming facts not in evidence. The rotation is merely irregular within the capabilities of our scheme of measurement, calculation, and observation. There is LOTS of evidence that the earth's rotation is irregular. VLBI, laser ranging of the moon, etc. This was known long before the atomic clock was invented, and it is why the definition of the second was changed from one based on earth rotation to one based on Newcomb's ephemerides, before the change to an atomic second. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Hebrides, Bailey: East backing northeast 5 or 6, decreasing 4 later in Hebrides. Rough in Bailey at first, otherwise moderate. Rain at times, fog patches. Moderate, occasionally very poor.
Re: F-ckin Leap Seconds, how do they work?
On Tue, Jul 03, 2012 at 11:33:22PM +0100, Tony Finch wrote: Keith Medcalf kmedc...@dessus.com wrote: You are assuming facts not in evidence. The rotation is merely irregular within the capabilities of our scheme of measurement, calculation, and observation. There is LOTS of evidence that the earth's rotation is irregular. VLBI, laser ranging of the moon, etc. This was known long before the atomic clock was invented, and it is why the definition of the second was changed from one based on earth rotation to one based on Newcomb's ephemerides, before the change to an atomic second. This. Shoot, seismic activity has a measurable effect. The best we can do is approximate it and align the timescales as needed. There's no lack of understanding here, just a changing planet. Now, changing your kernel's leap second handler and not testing it, well, you can't blame that one on the ITU or the aforementioned planet. --msa
RE: F-ckin Leap Seconds, how do they work?
Tony Finch fa...@hermes.cam.ac.uk wrote: Keith Medcalf kmedc...@dessus.com wrote: You are assuming facts not in evidence. The rotation is merely irregular within the capabilities of our scheme of measurement, calculation, and observation. There is LOTS of evidence that the earth's rotation is irregular. VLBI, laser ranging of the moon, etc. This was known long before the atomic clock was invented, and it is why the definition of the second was changed from one based on earth rotation to one based on Newcomb's ephemerides, before the change to an atomic second. What you mean is that it is subject to periodicities and forces which you do not understand, and that within your limited perception, this ignorance is taken as irregularity. Just because the system encompasses rules and properties beyond your understanding and observation does not mean that it is magic. It is impossible for the earth's rotation to be irregular, just as it is impossible for the orbit around the sun to be irreglar, or the orbit of the solar system within the galaxy, or the galaxy within the universe, or the universe within the multiverse, to be irregular. The irregularity is due to inability to comprehend the rather simple set of rules governing the motion, or failures of observation. Once upon a time (not too long ago) the orbit of Pluto was thought to be irregular. It was not. There was another body right where it would be expected to be found affecting the orbit of Pluto. All that was required to discover it was someone who applied logical thought processes rather than magical thought processes to the observed data. The earth's rotation and orbit is perfectly regular. Your error is one of assumption and a failure to admit that your knowledge is imperfect. ** your is the general y'all, not you in particular ** --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
Re: F-ckin Leap Seconds, how do they work?
On 7/3/2012 2:35 PM, Tony Finch wrote: Peter Lothberg r...@stupi.se wrote: As the definition of a atomic second is 9192631770 complete oscillations of cesium 133 between enery level 3 and 4, everyone can make a second in their lab, that's TAI. No, TAI isn't based on the SI second you realise in your lab. It's the SI second realised on the geoid by a large fleet of clocks. I think if anyone here is well aware of that that's be Peter:) The reason for the fleet of clocks is partly political, partly practical (cesium clocks are not the most precise... so averaging between a bunch of them is used to calibrate better master clocks). But in theory, if you can get the technical wrinkles worked out, you can derive the same frequency standard in your lab with a single instrument. (One more issue is that non-relativistic time is not only the frequency of oscillators, but also a reference point). --vadim
RE: F-ckin Leap Seconds, how do they work?
Keith Medcalf kmedc...@dessus.com wrote: What you mean is that it is subject to periodicities and forces which you do not understand, and that within your limited perception, this ignorance is taken as irregularity. Just because the system encompasses rules and properties beyond your understanding and observation does not mean that it is magic. You seem to have a strange interpretation of the word irregular. All I mean is that it does not rotate at a regular rate, i.e. smoothly. It is not a regular oscillator. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Cromarty, Forth, Tyne, Dogger: Southeast 4 or 5, decreasing 3 at times. Slight or moderate. Rain or drizzle, fog patches. Moderate, occasionally very poor.
Re: F-ckin Leap Seconds, how do they work?
Vadim Antonov a...@kotovnik.com wrote: But in theory, if you can get the technical wrinkles worked out, you can derive the same frequency standard in your lab with a single instrument. (One more issue is that non-relativistic time is not only the frequency of oscillators, but also a reference point). Your parenthetical point explains why TAI does not tick at the same rate as the SI second in your lab, expecially if your lab is (for example) in Colorado. You have to adjust the frequency depending on your difference in gravitational potential from the geoid. Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Biscay: West or southwest 4 or 5, decreasing 3 at times. Moderate. Rain then showers. Moderate or good, occasionally poor at first.
Re: F-ckin Leap Seconds, how do they work?
On Jul 3, 2012, at 1:08 PM, Keith Medcalf wrote: The system clock needs to be UTC, not UTC ± some offset stuck somewhere that keeps some form of running tally of the current leap second offset since the epoch. Nope. UTC *includes* leap seconds already. It's UT1 that does not. Are you suggesting that NTP timekeeping should be based on UT1? The system clock should be based on UT1 and should be monotonically increasing since this matches the common concept of time. Calculations done with this value are all based on it being UT1 and using the common notion of UT1 rules. The root cause of the difficulties is that someone decided that the system clock would not maintain wall clock time (UT1) but rather some other timebase and then step that time to keep it in sync with UT1. It only matches the common concept of time at some particular instant. Over the course of several years it will become less and less aligned with the common concept of time. Most people operate on the assumption that there are 86400*365.25 seconds per year overall and that every day is 86,400 seconds. UTC matches that common conception of time. UT1 does not because UT1 monotonically increments one second for every elapsed second of time and continues to drift out of synchronization with the celestial phenomena on which the common conception of time is based. NTP can keep time in UTC (or anything else) if it wants, but it should discipline the system clock to monotonically increasing UT1. This will break many many currently correct applications and is not a change that should be undertaken lightly. Especially not if it is intended to fix a moderately esoteric bug in a few things that crops up once per decade or so. Owen
Re: F-ckin Leap Seconds, how do they work?
On Jul 3, 2012, at 1:09 PM, Saku Ytti wrote: On (2012-07-03 12:46 -0700), Owen DeLong wrote: If you don't know that time is not monotonically increasing, then that only becomes a software bug when you codify your own ignorance into software you write. If only all software could be ordered from you Owen, but in practice this is not possible. Some code will be written less intelligent people. And reviewing any code doing foo = timestamp+offset and if now foo, virtually never expects time to move backwards. Sure, but even with that, 99% of it has only a passing 'interesting' effect and then recovers. UTC doesn't move backwards (it goes 59 - 60 - 00). TAI does not move backwards. Unixtime moves backwards, like spanish inquisition no one expects that. UTC (and the system clock) should not move backwards, but, rather they repeat second 59. UTC goes 58-59-00 most of the time, but during a leap second, it should go 58-59-59-00). It's not so much going backwards as dropping a chime. It is well known that leap seconds exist. Quite. But it is not well known that unixtime travels backwards. In part because it shouldn't actually do so. It should simply chime 59 twice. Owen
Re: F-ckin Leap Seconds, how do they work?
Tony Finch dot at dotat.at wrote No that is not correct, or at least it's nowhere near as simple as that. The atomic second was matched to the second of ephemeris time, and that was based on Newcomb's tables of the sun, which in effect used the average length of the second from the 1800s. http://ucolick.org/~sla/leapsecs/dutc.html Last fall we held a meeting to consider how UTC might be changed and what the implications of leaps seconds were. The proceedings fill 400 pages of a book. For the sound bite version (only 3 pictures) of leap seconds http://www.ucolick.org/~sla/leapsecs/amsci.html For a view of the international legal mess caused by leap seconds http://www.ucolick.org/~sla/leapsecs/epochtime.html For a blow-by-blow review of the international bureaucratic regulatory situation for leap seconds see http://www.ucolick.org/~sla/leapsecs/onlinebib.html For a worked example that could alleviate the disagreement between POSIX and leap seconds, and which might break the international stalemate http://www.ucolick.org/~sla/leapsecs/right+gps.html In there are also links to those 400 pages of the book, but I suggest that this forum is not the best place to rehash this information. -- Steve Allen s...@ucolick.orgWGS-84 (GPS) UCO/Lick Observatory--ISB Natural Sciences II, Room 165Lat +36.99855 1156 High StreetVoice: +1 831 459 3046 Lng -122.06015 Santa Cruz, CA 95064http://www.ucolick.org/~sla/ Hgt +250 m
