Re: [time-nuts] June 30 2015 leap second
d0ct0r wrote: Today, I did the check the settings for my BC637 card. I was surprised that its overwrite my manual setting for the Leap Event by following information: Time Settings: Mode : GPS Time Format: Binary Year : 1995 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 16 Scheduled Leap Event Time : 876614400 Scheduled Leap Event Flag : Insertion GPS Time Format: UTC Format IEEE Daylight Savings Flag : Enable Why are you wondering? This should be the expected result if your card receives and decodes the data from the GPS satellites. Sun, 12 Oct 1997 00:00:00 GMT. Its weird. I am going to re-insert it and will check it again later. New Time Settings are: Mode : GPS Time Format: Binary Year : 2015 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 16 Scheduled Leap Event Time : 1435708799 Scheduled Leap Event Flag : Insertion GPS Time Format: UTC Format IEEE Daylight Savings Flag : Enable I'd expect these will be overwritten again during GPS reception. However, as far as I can see the UTC parameters currently sent by the satellites still haven't been updated to reflect the upcoming leap second, so the date derived from the old week number in this parameter set is ambiguous. Also the event flag (insertion vs. deletion) can't be determined from the curent parameters. I'd expect that this is just an interpreting problem in the user interface. Also, my NTP, which rely on that card, didn't get the value for leap second event yet: # ntpq -c rv associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer, version=ntpd 4.2.6p5@1.2349 Mon Sep 22 20:41:39 UTC 2014 (14), processor=x86_64, system=Linux/3.2.0-74-generic, leap=00, stratum=1, precision=-23, rootdelay=0.000, rootdisp=8248.907, refid=BTFP, reftime=d85e7526.957a1b17 Mon, Jan 12 2015 11:30:30.583, clock=d85ec544.e1effe31 Mon, Jan 12 2015 17:12:20.882, peer=0, tc=4, mintc=3, offset=3.757, frequency=-243.698, sys_jitter=0.000, clk_jitter=1.328, clk_wander=15.616 What would you expect to see? Ntpd accepts and forwards leap second announcements only one day before the leap second event. If ntpd would accept a leap second warning right now and set the leap variable accordingly then all its NTP clients would try to insert a leap second at the end of January. I don't think this is what you want. By the way, are you sure the driver /127.127.x.0) you are using to let ntpd get the time from your PCI card supports passing on the leap second warning to ntpd? Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
The referenced article indicates that they apply the smear to their NTP servers and allow the clients to track the servers. This approach would place some limits on the minimum lead time you would need to implement the smear. 1) you would have to start early enough for the servers to detect the change. Unless Google has an internal policy to limit maxpoll you would expect the clients to be operating at the default value of 1024 seconds. They would have to start well before 1024 seconds to allow the clients to detect the change and start tracking. 2) NTP has a maximum slew rate of 500ppm ( http://doc.ntp.org/4.1.0/ntpd.htm) . In practice you wouldn't be able to use this full range because the clients would already have some error in their clocks. The scary part of the referenced article is in the third to last paragraph: and Google engineers developing code don’t have to worry about leap seconds. That seems like the kind of attitude that would have caused such a mess with computer timekeeping in the first place. On 1/11/2015 09:31, Tom Van Baak wrote: The google code is lie(t) = (1.0 - cos(pi * t / w)) / 2.0 and they are wise not to publish the actual window value, w. If it were me I'd make it somewhere between a couple of seconds or couple of minutes but I too would not make it a published or hardcoded constant. Here's the link again: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
I've often wondered why more systems don't use TAI or other similar time scales as their time source. If needed the time displayed to end users or third parties could be converted to UTC just prior to presentation or transmittal. For example a financial system that needs to time stamp individual transactions could sync their system clocks to TAI. As the difference between TAI and UTC changed (or was scheduled to change) a lookup table could be updated that would provide the offset between UTC and TAI for given date ranges. Sent from my iPad On 2015-01-10, at 7:49 AM, Jim Lux jim...@earthlink.net wrote: On 1/9/15 4:57 PM, Henry Hallam wrote: Such slewing solutions are OK for Google. They wouldn't work well for one of the systems I work with, which uses system time to calculate the position of a LEO satellite for purpose of pointing a 7.6 meter X-band dish. Half a second of error corresponds to a pointing error of 0.5 degrees, well outside the main lobe of the antenna beam. Which is why we use TAI in the space business and don't fool with this Greenwich Mean Time or Coordinated Universal Time which is discontinuous and potentially non-monotonic. We DO need to compensate for the earth's varying rotational speed, though, but that's just handled as a separate model for deep space, or for LEO, where the coordinate system is Earth Centered, absorbed into the spacecraft orbital elements.. nobody is going to use 1 year old ephemerides) I do find myself explaining exactly WHY we can't just use PC system time, etc. and periodic leap seconds are an object lesson in why not. (or, you can arrange to not being doing any operations at the moment of leap...that's been done too) ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
martin.burni...@burnicki.net said: So I think they smeared it over more than just a few minutes. I'd expect some hours, so standard NTP clients would just notify this as clock drift (oscillator frequency offset) which they'd have to compensate. Since ntpd's control loop is pretty slow it wouldn't respond quickly to smears over a few seconds our hours. NTP and/or most kernels have a limit on how far they are willing to push the clock. ntpd's limit is 500 ppm. It's common for normal clocks to be off 100 ppm, so you can't use all of that for leap-smearing. If you assume that you can slew at 100 ppm, then it will take 1 seconds to slew 1 second. That's assuming a step function. But Google uses cos to round off the corners, so the time will be longer. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Hi Tom, You are correct, but it does not really matter because it will not be instantaneous, and for a period of time that is well within the range of human perception, the clock will be off by more than you would normally expect. We have been talking about NTP being able to keep the time to within uS or better and this is a system that deliberately introduces an error a million times bigger. I am just surprised Time-Nuts would not go nuts about it :) Didier KO4BB On January 11, 2015 8:31:12 AM CST, Tom Van Baak t...@leapsecond.com wrote: Keep in mind that this system drives you to having pretty bad time for the better part of a whole day, on purpose... I realize that when the Hi Didier, The google article never claims the smear spans an entire day. I think you may be confusing references to the leap smear with a DIY digital clock someone on the list wanted to build (and they proposed using a slow 86400 second slew). The google code is lie(t) = (1.0 - cos(pi * t / w)) / 2.0 and they are wise not to publish the actual window value, w. If it were me I'd make it somewhere between a couple of seconds or couple of minutes but I too would not make it a published or hardcoded constant. Here's the link again: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html Again, I don't know what value they use, or even if they use the same value from one leap second to the next. If any of you have inside contacts with google and can find out let me know, off-list. Regardless, it should be possible to experimentally determine the smear duration by repeatedly using some google service that returns time-stamps during the day, hours, minutes, or seconds before and after June 30. It would make a nice posting for a time nut, or a research paper for a high school student or undergrad: Experimental Confirmation of Google's Leap Smear Algorithm. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- Sent from my Motorola Droid Razr HD 4G LTE wireless tracker while I do other things. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Today, I did the check the settings for my BC637 card. I was surprised that its overwrite my manual setting for the Leap Event by following information: Time Settings: Mode : GPS Time Format: Binary Year : 1995 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 16 Scheduled Leap Event Time : 876614400 Scheduled Leap Event Flag : Insertion GPS Time Format: UTC Format IEEE Daylight Savings Flag : Enable Sun, 12 Oct 1997 00:00:00 GMT. Its weird. I am going to re-insert it and will check it again later. New Time Settings are: Mode : GPS Time Format: Binary Year : 2015 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 16 Scheduled Leap Event Time : 1435708799 Scheduled Leap Event Flag : Insertion GPS Time Format: UTC Format IEEE Daylight Savings Flag : Enable Also, my NTP, which rely on that card, didn't get the value for leap second event yet: # ntpq -c rv associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer, version=ntpd 4.2.6p5@1.2349 Mon Sep 22 20:41:39 UTC 2014 (14), processor=x86_64, system=Linux/3.2.0-74-generic, leap=00, stratum=1, precision=-23, rootdelay=0.000, rootdisp=8248.907, refid=BTFP, reftime=d85e7526.957a1b17 Mon, Jan 12 2015 11:30:30.583, clock=d85ec544.e1effe31 Mon, Jan 12 2015 17:12:20.882, peer=0, tc=4, mintc=3, offset=3.757, frequency=-243.698, sys_jitter=0.000, clk_jitter=1.328, clk_wander=15.616 Regards, Vlad It's fragile enough that there have been accidental false leap-second events. Yes, for example if there have been GPS receivers which decoded the UTC parameters incorrectly, and started to announce a leap second when there wasn't one (end of September). That's why, for example, ntpd's leap second handling code has been changed in v4.2.6 to accept a leap second warning only if the warning is received from a majority of the configured servers. If you want to be sure you can also provide ntpd with a leap second file which is then (in current versions) considered as authentic source for leap second information. Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
I haven't looked at the raw data, but using the windows apps: a Trimble Resolution SMT is showing the leap pending a Motorola UT+ is not. lady heather is not Interesting. I don't see any leap-pending from a Z3801A. (or a KS-24361) Hi Hal, It's not that simple. There are many different levels of leap second notification. 1) IERS updates their ftp site (for bots) and sends email (for humans) indicating when the next leap second will occur. Days or weeks (and sometimes months) later, 2) GPS ground control uploads almanac information to the satellites with updated UTC parameters. Four values in page 18 of subframe 4 give the current UTC leap second delta and also an optional future UTC delta, with a GPS week (LS_f) and day number (DN) when that future delta will be current. By definition the leap second will occur at the end of a UTC (not GPS) day. In this way GPS can provide up to 256 weeks (~4.9 years) of advanced leap second information and support positive or negative leap seconds. Note there is no leap second warning *bit* in the GPS spec, per se. 3) Starting up to 12.5 minutes later, GPS receivers will see page 18 of subframe 4 from some or all SV and thus know not only the current UTC offset, bit when/if a different UTC offset will be valid in the distant future. Prior to this (e.g., cold start) there is no certainty of either the UTC offset or leap second state. 4a) Since UTC and leap seconds are not needed for navigation, some GPS receivers do not bother to tell the user about leap seconds at all. 4b) Some GPS receivers only give the user a leap second warning and so they must wait until the month in which the leap second is to be applied before they issue the warning. That means they may sit on the internal leap second information for many months. 4c) Other GPS receivers give the future date of the next leap second (if any). This is not a warning bit, but just the date/time of the next leap second. 4d) Especially dangerous are any GPS receivers that report only a leap second warning bit, but don't tell you which month it will occur. 5) Host software (e.g., GPSDO firmware, operating system, drivers, or apps) take this information and must only operate on it at the end of the appropriate UTC month. Hardcoded rules for June and December are frowned upon. It would be nice if we pooled together our resources and made a list of which GPS/GNSS receivers are 4a, 4b, 4c, or 4d. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Keep in mind that this system drives you to having pretty bad time for the better part of a whole day, on purpose... I realize that when the Hi Didier, The google article never claims the smear spans an entire day. I think you may be confusing references to the leap smear with a DIY digital clock someone on the list wanted to build (and they proposed using a slow 86400 second slew). The google code is lie(t) = (1.0 - cos(pi * t / w)) / 2.0 and they are wise not to publish the actual window value, w. If it were me I'd make it somewhere between a couple of seconds or couple of minutes but I too would not make it a published or hardcoded constant. Here's the link again: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html Again, I don't know what value they use, or even if they use the same value from one leap second to the next. If any of you have inside contacts with google and can find out let me know, off-list. Regardless, it should be possible to experimentally determine the smear duration by repeatedly using some google service that returns time-stamps during the day, hours, minutes, or seconds before and after June 30. It would make a nice posting for a time nut, or a research paper for a high school student or undergrad: Experimental Confirmation of Google's Leap Smear Algorithm. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
michael.c...@sfr.fr said: I havenât looked at the raw data, but using the windows apps: a Trimble Resolution SMT is showing the leap pending a Motorola UT+ is not. lady heather is not Interesting. I don't see any leap-pending from a Z3801A. (or a KS-24361) There is another interesting worm in this can... Various software in the chain from Paris to your PC may filter the leap-pending info. There was at least one bug in ntpd where it told the kernel to leap-tonight several months early. The way it's supposed to work is that ntpd tells the kernel leap-tonight, and the kernel will add/delete a leap second at midnight. That gives the ntp servers a whole day to propagate the leap-pending info to lower stratum servers and another day to turn it off by the next midnight. The T2 string from HP GPSDOs includes a slot which is +, -, or 0 for insert, delete, or none. You can ask it when the leap is scheduled, but the code didn't do that. It just assumed the leap was scheduled for the end of the current month. The fix was to add a filter to only pay attention to that flag in June and December. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
There are many systems for which the Google fix would not work in the current state of technology unless implemented by EVERYBODY synchronously. At least everybody who depends on precise time like banking and financial systems, let alone the physicists and many others... Keep in mind that this system drives you to having pretty bad time for the better part of a whole day, on purpose... I realize that when the alternative is a system crash, it may sound tempting, but it really is not a fix, a bandage at most. We have a term for that in French: emplâtre sur une jambe de bois, cast on a wooden leg. Didier KO4BB On Fri, Jan 9, 2015 at 6:57 PM, Henry Hallam he...@pericynthion.org wrote: Such slewing solutions are OK for Google. They wouldn't work well for one of the systems I work with, which uses system time to calculate the position of a LEO satellite for purpose of pointing a 7.6 meter X-band dish. Half a second of error corresponds to a pointing error of 0.5 degrees, well outside the main lobe of the antenna beam. Anecdotally yours, Henry On Fri, Jan 9, 2015 at 2:30 PM, Hal Murray hmur...@megapathdsl.net wrote: t...@patoka.org said: 1s/24h = 1/86400 which is approximately 12ppm. That means that Aging Offset could slow down my clock for 1 second if I'll apply the maximum value one day ahead (roughly). I need to do some experiments first. ;-) Its looks too unreliable for me. If you do it that way, your clock will be off by a whole second just before midnight when the leap-second brings it back into sync. If you tweak your clock from noon-noon, it will only be off by 1/2 second at midnight when the sign-bit of the error flips. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Hi If section 4 is going to turn in to a list of suspects to investigate and tabulate, I would add: 4 e) CDMA runs on GPS (not UTC) time. A “pure CDMA” GPSDO may be coded to ignore leap second data altogether. The ones I’m thinking about are the GPSTM boxes that put out very CDMA specific timing (pulse very other second not pps and all the rest). 4 f) GPS gizmos that report the leap second correctly and then handle it incorrectly (in a variety of ways..) when it occurs. Each time we have a leap second the net explodes with reports of these bugs. Yes, the second one opens a whole other can of worms. It’s pretty well documented already that different firmware rev’s have different issues. Since the Motorola Oncore modules have been around the longest, they seem to have the most information about these bugs. There is an old Motorola notification on the VP, UT, GT and M12 issues (notification_oncore.pdf). It’s no longer on the Motorola site, but its hopefully out on the net somewhere. Bob On Jan 11, 2015, at 9:02 AM, Tom Van Baak t...@leapsecond.com wrote: I haven't looked at the raw data, but using the windows apps: a Trimble Resolution SMT is showing the leap pending a Motorola UT+ is not. lady heather is not Interesting. I don't see any leap-pending from a Z3801A. (or a KS-24361) Hi Hal, It's not that simple. There are many different levels of leap second notification. 1) IERS updates their ftp site (for bots) and sends email (for humans) indicating when the next leap second will occur. Days or weeks (and sometimes months) later, 2) GPS ground control uploads almanac information to the satellites with updated UTC parameters. Four values in page 18 of subframe 4 give the current UTC leap second delta and also an optional future UTC delta, with a GPS week (LS_f) and day number (DN) when that future delta will be current. By definition the leap second will occur at the end of a UTC (not GPS) day. In this way GPS can provide up to 256 weeks (~4.9 years) of advanced leap second information and support positive or negative leap seconds. Note there is no leap second warning *bit* in the GPS spec, per se. 3) Starting up to 12.5 minutes later, GPS receivers will see page 18 of subframe 4 from some or all SV and thus know not only the current UTC offset, bit when/if a different UTC offset will be valid in the distant future. Prior to this (e.g., cold start) there is no certainty of either the UTC offset or leap second state. 4a) Since UTC and leap seconds are not needed for navigation, some GPS receivers do not bother to tell the user about leap seconds at all. 4b) Some GPS receivers only give the user a leap second warning and so they must wait until the month in which the leap second is to be applied before they issue the warning. That means they may sit on the internal leap second information for many months. 4c) Other GPS receivers give the future date of the next leap second (if any). This is not a warning bit, but just the date/time of the next leap second. 4d) Especially dangerous are any GPS receivers that report only a leap second warning bit, but don't tell you which month it will occur. 5) Host software (e.g., GPSDO firmware, operating system, drivers, or apps) take this information and must only operate on it at the end of the appropriate UTC month. Hardcoded rules for June and December are frowned upon. It would be nice if we pooled together our resources and made a list of which GPS/GNSS receivers are 4a, 4b, 4c, or 4d. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
I don't know for sure which category the Ball/Efratom MGPS (as found in the MFS-XXX Modular Frequency Standard frames) is in yet But the MGPS has a screen labeled Current Leap Second, that according to the manual: The display indicates the date and time of the current leap second. Leap second data are hourly updated by GPS satellite transmission (automatically). A leap second can also be programed by the operator. To program a leap second date and time, it is first necessary to select the Edit menu by pressing the pushbutton E I had to remove the lithium cell from my unit when I was servicing it, so it is now displaying some hard reset default value: Date 17 05 27 Time 23:59:00 If the Current Leap Second is indeed updated hourly, and my display persists in showing a nonsense value, I am wondering if it might be that it thinks it is in a manually programmed leap second mode? Perhaps I should manually program it to: 00 00 00 00:00:00, and, hope it will get the clue that it is supposed to automagically update the Current Leap Second from the GPS packets? I would hate for my MGPS to miss the leap second party because the manual was unclear. -Chuck Harris Tom Van Baak wrote: I haven't looked at the raw data, but using the windows apps: a Trimble Resolution SMT is showing the leap pending a Motorola UT+ is not. lady heather is not Interesting. I don't see any leap-pending from a Z3801A. (or a KS-24361) Hi Hal, It's not that simple. There are many different levels of leap second notification. 1) IERS updates their ftp site (for bots) and sends email (for humans) indicating when the next leap second will occur. Days or weeks (and sometimes months) later, 2) GPS ground control uploads almanac information to the satellites with updated UTC parameters. Four values in page 18 of subframe 4 give the current UTC leap second delta and also an optional future UTC delta, with a GPS week (LS_f) and day number (DN) when that future delta will be current. By definition the leap second will occur at the end of a UTC (not GPS) day. ... ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Tom Van Baak wrote: I haven't looked at the raw data, but using the windows apps: a Trimble Resolution SMT is showing the leap pending a Motorola UT+ is not. lady heather is not Interesting. I don't see any leap-pending from a Z3801A. (or a KS-24361) Hi Hal, It's not that simple. There are many different levels of leap second notification. 1) IERS updates their ftp site (for bots) and sends email (for humans) indicating when the next leap second will occur. Days or weeks (and sometimes months) later, 2) GPS ground control uploads almanac information to the satellites with updated UTC parameters. Four values in page 18 of subframe 4 give the current UTC leap second delta and also an optional future UTC delta, with a GPS week (LS_f) and day number (DN) when that future delta will be current. By definition the leap second will occur at the end of a UTC (not GPS) day. In this way GPS can provide up to 256 weeks (~4.9 years) of advanced leap second information and support positive or negative leap seconds. Yes, and since the GPS UTC parameters just provide the difference to GPS time (in seconds) before and after the leap event time, they could even announce a leap event where more than 1 second is inserted or deleted at once. ;-) I'm not aware of any other timing system that could handle this, though. Note there is no leap second warning *bit* in the GPS spec, per se. 3) Starting up to 12.5 minutes later, GPS receivers will see page 18 of subframe 4 from some or all SV and thus know not only the current UTC offset, bit when/if a different UTC offset will be valid in the distant future. Prior to this (e.g., cold start) there is no certainty of either the UTC offset or leap second state. 4a) Since UTC and leap seconds are not needed for navigation, some GPS receivers do not bother to tell the user about leap seconds at all. 4b) Some GPS receivers only give the user a leap second warning and so they must wait until the month in which the leap second is to be applied before they issue the warning. That means they may sit on the internal leap second information for many months. 4c) Other GPS receivers give the future date of the next leap second (if any). This is not a warning bit, but just the date/time of the next leap second. 4d) Especially dangerous are any GPS receivers that report only a leap second warning bit, but don't tell you which month it will occur. 5) Host software (e.g., GPSDO firmware, operating system, drivers, or apps) take this information and must only operate on it at the end of the appropriate UTC month. Hardcoded rules for June and December are frowned upon. It would be nice if we pooled together our resources and made a list of which GPS/GNSS receivers are 4a, 4b, 4c, or 4d. It also depends on *how* the leap second warning is made available. If an application can read the GPS UTC parameter set then it can compute it as soon as the sats start to broadcast it. There are formats of time string output by GPS receivers which only include the leap second warning 1 hour or 1 day before the event. NMEA sentences don't include it at all, AFAIK. Binary messages may, depending on the manufacturer. IRIG time code signals also don't provide a leap second *warning* flag, except the IEEE codes 1344 and C37.118, which only output this 10 seconds or 1 minute (don't remember exactly without looking) before the event. Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Tom Van Baak wrote: Keep in mind that this system drives you to having pretty bad time for the better part of a whole day, on purpose... I realize that when the Hi Didier, The google article never claims the smear spans an entire day. I think you may be confusing references to the leap smear with a DIY digital clock someone on the list wanted to build (and they proposed using a slow 86400 second slew). The google code is lie(t) = (1.0 - cos(pi * t / w)) / 2.0 and they are wise not to publish the actual window value, w. If it were me I'd make it somewhere between a couple of seconds or couple of minutes but I too would not make it a published or hardcoded constant. Hm, the article says, It also made sure the updates were sufficiently small so that any software running on the servers that were doing synchronization actions or had Chubby locks wouldn't lose those locks or abandon any operations. So I think they smeared it over more than just a few minutes. I'd expect some hours, so standard NTP clients would just notify this as clock drift (oscillator frequency offset) which they'd have to compensate. Since ntpd's control loop is pretty slow it wouldn't respond quickly to smears over a few seconds our hours. Here's the link again: http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html Again, I don't know what value they use, or even if they use the same value from one leap second to the next. If any of you have inside contacts with google and can find out let me know, off-list. Regardless, it should be possible to experimentally determine the smear duration by repeatedly using some google service that returns time-stamps during the day, hours, minutes, or seconds before and after June 30. It would make a nice posting for a time nut, or a research paper for a high school student or undergrad: Experimental Confirmation of Google's Leap Smear Algorithm. Yes, interesting idea! Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
On 1/9/15 4:57 PM, Henry Hallam wrote: Such slewing solutions are OK for Google. They wouldn't work well for one of the systems I work with, which uses system time to calculate the position of a LEO satellite for purpose of pointing a 7.6 meter X-band dish. Half a second of error corresponds to a pointing error of 0.5 degrees, well outside the main lobe of the antenna beam. Which is why we use TAI in the space business and don't fool with this Greenwich Mean Time or Coordinated Universal Time which is discontinuous and potentially non-monotonic. We DO need to compensate for the earth's varying rotational speed, though, but that's just handled as a separate model for deep space, or for LEO, where the coordinate system is Earth Centered, absorbed into the spacecraft orbital elements.. nobody is going to use 1 year old ephemerides) I do find myself explaining exactly WHY we can't just use PC system time, etc. and periodic leap seconds are an object lesson in why not. (or, you can arrange to not being doing any operations at the moment of leap...that's been done too) ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
On 1/10/15 1:25 PM, Hal Murray wrote: jim...@earthlink.net said: Which is why we use TAI in the space business and don't fool with this Greenwich Mean Time or Coordinated Universal Time which is discontinuous and potentially non-monotonic. Does the system clock on your PCs run on TAI or do they have a separate clock for space applications? Is that even a sensible question? Do you use PCs running traditional OSes? A good question. We run traditional OSes (Tons of Suns running Unix in the deep space network), but newer systems run Linux or Windows. That's for terrestrial applications. Software conversions used between TAI and user time on whatever platform, and leap seconds are handled in an ad-hoc way (in the sense that there's no particular standardized way). We distribute TAI time via a variety of timecodes (there's IRIG-B, for instance) and other means (NTP, etc.) NTP is UTC, so it has to be converted to TAI in software. Lots of dedicated boxes that deal with time. In flight, VxWorks and RTEMS: I have a lot more familiarity with the latter. In flight, until recently, we don't ever convert from raw spacecraft clock - SCLK which is just a free running counter driven from some oscillator. Someone on the ground figures out the offset and rate of the oscillator, and if you want something to occur at 12:34:53, you convert that to SCLK and say do this at time X where X is a binary number of some sort. This is gradually changing. That said, when a formatted time is used, I think CCSDS Unsegmented Time Code (CUC) is most common, and it's TAI seconds and fractions of seconds. That is, the basic time is in integer seconds, with some multiple of 8 bits worth of fractional seconds (e.g. if you have 1 octet of fine time, it would be in units of 2^-8 seconds, etc.). At least that's what *I* am using these days http://public.ccsds.org/publications/archive/301x0b4e1.pdf latest version has stuff about security and more discussion about the various kinds of time (UT1, TAI, GMT, UTC, etc.) ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
jim...@earthlink.net said: Which is why we use TAI in the space business and don't fool with this Greenwich Mean Time or Coordinated Universal Time which is discontinuous and potentially non-monotonic. Does the system clock on your PCs run on TAI or do they have a separate clock for space applications? Is that even a sensible question? Do you use PCs running traditional OSes? -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Such slewing solutions are OK for Google. They wouldn't work well for one of the systems I work with, which uses system time to calculate the position of a LEO satellite for purpose of pointing a 7.6 meter X-band dish. Half a second of error corresponds to a pointing error of 0.5 degrees, well outside the main lobe of the antenna beam. Anecdotally yours, Henry On Fri, Jan 9, 2015 at 2:30 PM, Hal Murray hmur...@megapathdsl.net wrote: t...@patoka.org said: 1s/24h = 1/86400 which is approximately 12ppm. That means that Aging Offset could slow down my clock for 1 second if I'll apply the maximum value one day ahead (roughly). I need to do some experiments first. ;-) Its looks too unreliable for me. If you do it that way, your clock will be off by a whole second just before midnight when the leap-second brings it back into sync. If you tweak your clock from noon-noon, it will only be off by 1/2 second at midnight when the sign-bit of the error flips. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
t...@patoka.org said: 1s/24h = 1/86400 which is approximately 12ppm. That means that Aging Offset could slow down my clock for 1 second if I'll apply the maximum value one day ahead (roughly). I need to do some experiments first. ;-) Its looks too unreliable for me. If you do it that way, your clock will be off by a whole second just before midnight when the leap-second brings it back into sync. If you tweak your clock from noon-noon, it will only be off by 1/2 second at midnight when the sign-bit of the error flips. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Tom Van Baak wrote: I couldn't help noticing that Debian just issued an update to tzone, so that means Linux systems now know about the leap second. -Chuck Harris Hi Chuck, Linux systems now know about the leap second -- this is a very dangerous assumption. And one reason why leap seconds have gotten out of hand the past decade. Just because you observe one tz update from Debian does not imply that all Linux systems on planet earth (or in space) magically know about leap seconds. There must be millions (billions?) of embedded or isolated systems -- from web servers to desktops to military systems to gadgets to Raspberry Pi's to mobile phones, that have not, and will not ever receive this update. And that's where the new tzdist protocol comes into the game, which can be used to supply leap second information to time *servers* which need to send leap second warnings to their clients. Systems which are simply time clients can receive the leap second warning via the usual protocols like NTP or PTP/IEEE1588. Of cours it must be sure that the information is also *evaluated* by the client software. Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Reading about leap seconds for the past two days, I found that common solution for it - just encode leap second event proactively and wait for it. Of course that possible only if device has that option. For example, BC637PCI has a menu item 7. Program Leap Event Seconds. Which I did. Now, if I do the request for time settings, its shows me following: Time Settings: Mode : GPS Time Format: Binary Year : 2015 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 16 Scheduled Leap Event Time : 1435708799 Scheduled Leap Event Flag : Insertion GPS Time Format: UTC Format IEEE Daylight Savings Flag : Enable Scheduled Leap Event Time - is so-called UNIX time. However, I am not sure where its take number 16 (Current Leap Seconds). Its definitely was not programmed there by me. Concerning of my clock project, I am thinking about best approach how to set up leap second procedure. I mean which time exactly I'll need to do correction for my clock (set time on RTC module). There is two options, I think. One: to reset RTC at July 1, 00:00:00 and set it back to June 30, 23:59:00. Or, at July 1, 00:00:01, set RTC back to July 1 00:00:00 and then at July 1 00:00:01 reset RTC with occurrance of raising edge of 1PPS. I would prefer to play with July 1, because in this case I don't need to do much calculations to transfer RTC time to number of seconds, decrement it by 1 second, transfer it back to BCD format and write it back to RTC. Instead, I'll need just read/write RTC register which keeps number of seconds inside. Regards, Vlad Just because you observe one tz update from Debian does not imply that all Linux systems on planet earth (or in space) magically know about leap seconds. There must be millions (billions?) of embedded or isolated systems -- from web servers to desktops to military systems to gadgets to Raspberry Pi's to mobile phones, that have not, and will not ever receive this update. -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
On Fri, Jan 9, 2015 at 3:21 PM, Martin Burnicki martin.burni...@burnicki.net wrote: Systems which are simply time clients can receive the leap second warning via the usual protocols like NTP or PTP/IEEE1588. Indeed, they can. Even when there hasn't been a leap-second. Practically all internet (and otherwise?) time distribution is unauthenticated, the leap second itself is unauthenticated. It's fragile enough that there have been accidental false leap-second events. ... one of many reasons I'd prefer leap seconds went away though I've personally had great fun observing them in the past. (and, I suspect, they may have been one of the first reasons I became interested in precise time keeping). ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
This is an issue indeed. Here is what I get from MySQL Data Base support site: Before MySQL 5.0.74, if the operating system is configured to return leap seconds from OS time calls or if the MySQL server uses a time zone definition that has leap seconds, functions such as NOW() could return a value having a time part that ends with :59:60 or :59:61. If such values are inserted into a table, they would be dumped as is by mysqldump but considered invalid when reloaded, leading to backup/restore problems. As of MySQL 5.0.74, leap second values are returned with a time part that ends with :59:59. This means that a function such as NOW() can return the same value for two or three consecutive seconds during the leap second. It remains true that literal temporal values having a time part that ends with :59:60 or :59:61 are considered invalid. Last time it was quite a pain: Machines running the mighty Amadeus Altea system were brought down soon after an extra second was added to Coordinated Universal Time (UTC) at midnight on Saturday, 30 June. The bonus second was inserted at the direction of time boffins to keep UTC synchronised with Earth's slowing rotation. The Altea system was taken offline for an hour, and staff at Qantas and Virgin Australia had to check in passengers manually, disrupting flight plans. Google's solution looks pretty amazing. The slowing down the clock by milliseconds as the event approach. May be that an option to play with Oscillator Aging register. In accordance with data sheet, the Aging Offset register takes a user-provided value to add to or subtract from the factory-trimmed value that adjusts the accuracy of the time base. The Aging Offset code is encoded in two’s complement, with bit 7 representing the SIGN bit and a valid range of ±127. One LSB typically represents a 0.12ppm change in frequency. The change in ppm per LSB is the same over the operating temperature range. Positive offsets slow the time base and negative offsets quicken the time base. So, using that I could achieve 127x0.12 = 15ppm change. 1s/24h = 1/86400 which is approximately 12ppm. That means that Aging Offset could slow down my clock for 1 second if I'll apply the maximum value one day ahead (roughly). I need to do some experiments first. ;-) Its looks too unreliable for me. On , Martin Burnicki wrote: Gregory Maxwell wrote: On Fri, Jan 9, 2015 at 3:21 PM, Martin Burnicki martin.burni...@burnicki.net wrote: Systems which are simply time clients can receive the leap second warning via the usual protocols like NTP or PTP/IEEE1588. Indeed, they can. Even when there hasn't been a leap-second. Practically all internet (and otherwise?) time distribution is unauthenticated, the leap second itself is unauthenticated. ... and even the time you get via NTP or PTP is usually not authenticated. So you can trust the time and leap second warning, or you shouldn't trust either. It's fragile enough that there have been accidental false leap-second events. Yes, for example if there have been GPS receivers which decoded the UTC parameters incorrectly, and started to announce a leap second when there wasn't one (end of September). That's why, for example, ntpd's leap second handling code has been changed in v4.2.6 to accept a leap second warning only if the warning is received from a majority of the configured servers. If you want to be sure you can also provide ntpd with a leap second file which is then (in current versions) considered as authentic source for leap second information. Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
d0ct0r wrote: Reading about leap seconds for the past two days, I found that common solution for it - just encode leap second event proactively and wait for it. Of course that possible only if device has that option. For example, BC637PCI has a menu item 7. Program Leap Event Seconds. Which I did. Now, if I do the request for time settings, its shows me following: Time Settings: Mode : GPS Time Format: Binary Year : 2015 Local Offset : 0.0 Propagation Delay : 0 Current Leap Seconds : 16 Scheduled Leap Event Time : 1435708799 Scheduled Leap Event Flag : Insertion GPS Time Format: UTC Format IEEE Daylight Savings Flag : Enable Scheduled Leap Event Time - is so-called UNIX time. However, I am not sure where its take number 16 (Current Leap Seconds). Its definitely was not programmed there by me. 16 s is the current difference between GPS system time and UTC, which will increase to 17 after the next leap second. It is part of the UTC data set broadcasted by the satellites. I'd expect that in a few days the GPS satellites start broadcasting the leap second announcement, and then yourGPS receiver should also find out by itself *when* the leap second will occur, and what the UTC offset will be thereafter. When I looked this morning the sats did't broadcast this information, yet. Concerning of my clock project, I am thinking about best approach how to set up leap second procedure. I mean which time exactly I'll need to do correction for my clock (set time on RTC module). There is two options, I think. One: to reset RTC at July 1, 00:00:00 and set it back to June 30, 23:59:00. Or, at July 1, 00:00:01, set RTC back to July 1 00:00:00 and then at July 1 00:00:01 reset RTC with occurrance of raising edge of 1PPS. I would prefer to play with July 1, because in this case I don't need to do much calculations to transfer RTC time to number of seconds, decrement it by 1 second, transfer it back to BCD format and write it back to RTC. Instead, I'll need just read/write RTC register which keeps number of seconds inside. As said, once the sats start broadcasting this information your software should be able to read the time and leap second status from the PCI card, if the API supports this. How you can handle this to set your clock depends on the capabilites of your clock, and its API. Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Gregory Maxwell wrote: On Fri, Jan 9, 2015 at 3:21 PM, Martin Burnicki martin.burni...@burnicki.net wrote: Systems which are simply time clients can receive the leap second warning via the usual protocols like NTP or PTP/IEEE1588. Indeed, they can. Even when there hasn't been a leap-second. Practically all internet (and otherwise?) time distribution is unauthenticated, the leap second itself is unauthenticated. ... and even the time you get via NTP or PTP is usually not authenticated. So you can trust the time and leap second warning, or you shouldn't trust either. It's fragile enough that there have been accidental false leap-second events. Yes, for example if there have been GPS receivers which decoded the UTC parameters incorrectly, and started to announce a leap second when there wasn't one (end of September). That's why, for example, ntpd's leap second handling code has been changed in v4.2.6 to accept a leap second warning only if the warning is received from a majority of the configured servers. If you want to be sure you can also provide ntpd with a leap second file which is then (in current versions) considered as authentic source for leap second information. Martin ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Correct me if I'm wrong, but as I understand it the tzfile in the tzone package is not used to update the system time - that relies on NTP or similar. Rather, the leap second info in the tzone files is made available for applications to use, primarily for calculating time differences in the past. Henry On Fri, Jan 9, 2015 at 6:17 AM, Tom Van Baak t...@leapsecond.com wrote: I couldn't help noticing that Debian just issued an update to tzone, so that means Linux systems now know about the leap second. -Chuck Harris Hi Chuck, Linux systems now know about the leap second -- this is a very dangerous assumption. And one reason why leap seconds have gotten out of hand the past decade. Just because you observe one tz update from Debian does not imply that all Linux systems on planet earth (or in space) magically know about leap seconds. There must be millions (billions?) of embedded or isolated systems -- from web servers to desktops to military systems to gadgets to Raspberry Pi's to mobile phones, that have not, and will not ever receive this update. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
I couldn't help noticing that Debian just issued an update to tzone, so that means Linux systems now know about the leap second. -Chuck Harris Hi Chuck, Linux systems now know about the leap second -- this is a very dangerous assumption. And one reason why leap seconds have gotten out of hand the past decade. Just because you observe one tz update from Debian does not imply that all Linux systems on planet earth (or in space) magically know about leap seconds. There must be millions (billions?) of embedded or isolated systems -- from web servers to desktops to military systems to gadgets to Raspberry Pi's to mobile phones, that have not, and will not ever receive this update. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
I couldn't help noticing that Debian just issued an update to tzone, so that means Linux systems now know about the leap second. -Chuck Harris Tim Shoppa wrote: I'm not sure there's any computer time package that correctly disambiguates 23:59:59 vs 23:59:60 in UTC timestamps in a general purpose way. Some software simply rejects 23:59:60 UTC as invalid, some will quietly map it to 23:59:59 effectively making those two seconds impossible to distinguish. There are important systems in the world, those that genuinely have to distinguish between those two seconds, that do all timekeeping in TAI or GPS timescales instead of UTC. I think the Olsen timezone database/library does support TAI. I don't know if the Olsen timzone library supports GPS. V.P., since you mention Perl and leap seconds, I'd like to point out that there's a very useful Perl library for computing delta times around leapsecond jumps: http://search.cpan.org/~drolsky/DateTime-1.12/lib/DateTime/LeapSecond.pm This particular library is useful if you need to know the correct delta time between UTC timestamps but have chosen to ignore the ambiguity problem of correctly marking the leapsecond itself. The newest announced leap second is not in the table of leapseconds built into the code yet, but it's a simple matter to add it (cut and paste from the IPERS). Tim. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
in advance. When either of the two flags is set, the kernel will trigger the leap event in the last seconds of the current day. GPS should announce the pending leap second not long after the IERS announcement. I haven't checked my clocks yet but it may already be out there. I haven’t looked at the raw data, but using the windows apps: a Trimble Resolution SMT is showing the leap pending a Motorola UT+ is not. lady heather is not u-Center does not appear to provide the status for Ublox receivers. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
t...@patoka.org said: The question is how usually GPS modules handle leap seconds ? Is it satelates who send UTC time to GPS module or GPS module has firmware with leap second information hard-coded ? The satellites send GPS time with a low bandwidth footnote that provides the offset to UTC and another optional footnote with the time of the next leap second. I think you can see this as a 15 second jump if you watch a GPS receiver doing a cold start. I mean really cold as in no memory at all rather than it has battery backed memory but has been off for several months. After several months, the RTC has probably drifted and/or the almanac is no longer helpful, but the UTC offset probably hasn't changed. (especially for the past few years) It might be fun to warm up some low cost GPS receivers just before the great leap, power them off for several weeks around the leap, then see how they work when starting up post leap. The question is do they remember the next leap as well as the (old) offset. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
The difference between GPS time and UTC (due to leap seconds) is broadcast in the GPS navigation message[1] so all but the most poorly designed GPS modules should take care of it and output the correct UTC time. Henry, This is not quite true. First, page 18 of subframe 4 is only broadcast every 12.5 minutes so on a cold start worst case you wait up to 12.5 minutes before the receiver can *reliably* switch from GPS time to UTC time. This would not likely be an issue for the OP since his clock would keep the GPS receiver powered-on. Second, the OP is building a clock. A precise clock needs a 1PPS and it needs to know what date-time that 1PPS *will* be. The NMEA sentences only tell you what date-time the 1PPS *was*. This is the crux of the problem. Two solutions: 1) relax the requirements of the clock and allow it to display NMEA time, which will be late by tens to hundreds of ms. This also assumes the NMEA implementation of the receiver outputs hh:59:60 (many don't). Or 2), use proprietary binary messages from the receiver to get advanced warning of a pending leap second event and then role your own leap second special case code. The latter solution has a rare timing window if you turn on the clock too close to the leap second itself. /tvb ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
The difference between GPS time and UTC (due to leap seconds) is
broadcast in the GPS navigation message[1] so all but the most poorly
designed GPS modules should take care of it and output the correct UTC
time.
I'm not going to get into the mess of unix epoch time. Basically,
it's not a continuous time scale. There is some information on the
wikipedia page[2], and plenty of discussion on various mailing lists
such as LEAPSECS.
Henry
[1] Specifically, page 18 of subframe 4 - see IS-GPS-200G page 112,
114 and 119-121.
[2] https://en.wikipedia.org/wiki/Unix_time#Leap_seconds
On Tue, Jan 6, 2015 at 1:01 PM, d0ct0r t...@patoka.org wrote:
Hello,
As I am in the process of creation of my own Nixie clocks. And it probably
good time frame to clarify one thing about leap seconds. In my project I am
using GPS module as an option to have current UTC time and also to have 1PPS
signal to do auto-adjustment for external RTC module. The question is how
usually GPS modules handle leap seconds ? Is it satelates who send UTC time
to GPS module or GPS module has firmware with leap second information
hard-coded ?
The same question is for UNIX epoch time. How computers knows if it is
necessary to add leap seconds ? Lets say I am using very simple script to
calculate UNIX time for specified date:
#!/usr/bin/perl
use Time::Local;
my ($d, $m, $y);
my $time;
@myYears = ('01/06/2000', '01/06/2015', '01/06/2038', '01/06/3000');
foreach (@myYears) {
($d, $m, $y) = split '/', $_;
$time = timelocal(0,0,0,$d,$m-1,$y);
printf %ld\n\r, $time;
}
==
It will produce the following output:
959832000
1433131200
2158977600
32516740800
I am not sure if its take leap second consideration. Most likely not. And
that means its only accurate for the present and pas time. Right ? For my
clock I already implement the function for the leap second and I am able to
add/remove number of seconds from the time I receiving from GPS or any other
source. But it will be more inetersting if clock could do it automagically
and shows me that famous 60 number without human interaction. Any advise
for this ? Thanks !
Regards,
V.P.
On , Tom Van Baak wrote:
Just announced: there will be a positive leap second at the end of
June 30 2015 UTC (that's Wednesday July 1st for most of the world).
As usual we time nuts will have a leap second party -- where we
capture and share the magic hh:59:60 display on as many different
clocks and instruments as possible.
/tvb
More info:
ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
http://hpiers.obspm.fr/eop-pc/
And for those of you who want to know how long each day really is:
ftp://hpiers.obspm.fr/iers/bul/bulb_new/bulletinb.dat
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
WBW,
V.P.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Tom, Thanks for the comments ! In my design I am using NMEA as an option to set initial time on the clock. Its just faster and more convenient than doing it manually. And in the other (rare) occasions when clock logic could decide to sync. RTC module time with time received from GPS module. Basically I decide not to relay on GPS NMEA too much. My clock using 1PPS signal coming from internal GPS module or from external source connected to the device. That 1PPS and 32kHz signal from RTC module, connected to the MCU timers. So, I know for sure if RTC module generate its 32k signal slower/faster than it should be. If the difference between of those two signals become too big, clock will do autocorrection for the RTC oscillator to trim the value for Aging Register. RTC module has accuracy 2ppm. I think it suppose to keep the time well. Initially I was thinking that GPS will receive hh:59:60 NMEA message and I could use it as it is. But now I think I'll add some more code to handle such wonderful thing as a leap second event. I am going to create subroutines which will allow me to enter and keep leaps second event in battery backed SRAM and apply it as that even occurred. Unfortunately it will need the human interaction to set up leap second events. But if I'll leave the clock logic as it is now, I'll need to correct time on the clock any way. Since 1PPS just keep RTC oscillator in tact. But time on the clock will be 1 second ahead. -- WBW, V.P. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Tim, I was using perl as a tool to calculate UNIX time. As my project based on STM32 MCU, I have no option to use time libraries. And I dont' think its applcable for my project. I am thinking what exactly of that UNIX time is. Looks like its using simple constants, like we have 86400 seconds per day, we have 365/366 days per year. And we have certain leap years with strict rule to identify it. For the clock to use on a desk, its should be sufficient to avoid confusion with rest of the world. ;-) In the other words, looking to current UNIX time we could identify the current date/time as most people see it. But its give us zero info about actual number of seconds passed since Thursday, 1 January 1970, 00:00:00. Regards, V.P. V.P., since you mention Perl and leap seconds, I'd like to point out that there's a very useful Perl library for computing delta times around leapsecond jumps: http://search.cpan.org/~drolsky/DateTime-1.12/lib/DateTime/LeapSecond.pm [6] This particular library is useful if you need to know the correct delta time between UTC timestamps but have chosen to ignore the ambiguity problem of correctly marking the leapsecond itself. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
I think you can see this as a 15 second jump if you watch a GPS receiver doing a cold start. I mean really cold as in no memory at all rather than it t...@patoka.org said: Exactly ! I saw that behaviour few times.But I was thinking its because of some very old satelites which knows nothing about recent leap seconds send that information to the air. Yeah, I know.. So naive... ;-) I have my T-Bolt running 24x ... Does anybody know the details of the TBolt? Does it have any way to remember the almanac or time without external power? I looked at a few pictures from the net and didn't see anything that looked appropriate, but I didn't pull the cover off mine. A large cap would probably provide a few minutes to hours without using super-cap technology which probably didn't exist when the TBolt was designed or adding nasty chemicals that batteries usually contain. -- These are my opinions. I hate spam. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
I'm not sure there's any computer time package that correctly disambiguates
23:59:59 vs 23:59:60 in UTC timestamps in a general purpose way. Some
software simply rejects 23:59:60 UTC as invalid, some will quietly map it
to 23:59:59 effectively making those two seconds impossible to distinguish.
There are important systems in the world, those that genuinely have to
distinguish between those two seconds, that do all timekeeping in TAI or
GPS timescales instead of UTC. I think the Olsen timezone database/library
does support TAI. I don't know if the Olsen timzone library supports GPS.
V.P., since you mention Perl and leap seconds, I'd like to point out that
there's a very useful Perl library for computing delta times around
leapsecond jumps:
http://search.cpan.org/~drolsky/DateTime-1.12/lib/DateTime/LeapSecond.pm
This particular library is useful if you need to know the correct delta
time between UTC timestamps but have chosen to ignore the ambiguity problem
of correctly marking the leapsecond itself.
The newest announced leap second is not in the table of leapseconds built
into the code yet, but it's a simple matter to add it (cut and paste from
the IPERS).
Tim.
On Tue, Jan 6, 2015 at 4:01 PM, d0ct0r t...@patoka.org wrote:
Hello,
As I am in the process of creation of my own Nixie clocks. And it probably
good time frame to clarify one thing about leap seconds. In my project I am
using GPS module as an option to have current UTC time and also to have
1PPS signal to do auto-adjustment for external RTC module. The question is
how usually GPS modules handle leap seconds ? Is it satelates who send UTC
time to GPS module or GPS module has firmware with leap second information
hard-coded ?
The same question is for UNIX epoch time. How computers knows if it is
necessary to add leap seconds ? Lets say I am using very simple script to
calculate UNIX time for specified date:
#!/usr/bin/perl
use Time::Local;
my ($d, $m, $y);
my $time;
@myYears = ('01/06/2000', '01/06/2015', '01/06/2038', '01/06/3000');
foreach (@myYears) {
($d, $m, $y) = split '/', $_;
$time = timelocal(0,0,0,$d,$m-1,$y);
printf %ld\n\r, $time;
}
==
It will produce the following output:
959832000
1433131200
2158977600
32516740800
I am not sure if its take leap second consideration. Most likely not. And
that means its only accurate for the present and pas time. Right ? For my
clock I already implement the function for the leap second and I am able to
add/remove number of seconds from the time I receiving from GPS or any
other source. But it will be more inetersting if clock could do it
automagically and shows me that famous 60 number without human
interaction. Any advise for this ? Thanks !
Regards,
V.P.
On , Tom Van Baak wrote:
Just announced: there will be a positive leap second at the end of
June 30 2015 UTC (that's Wednesday July 1st for most of the world).
As usual we time nuts will have a leap second party -- where we
capture and share the magic hh:59:60 display on as many different
clocks and instruments as possible.
/tvb
More info:
ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
http://hpiers.obspm.fr/eop-pc/
And for those of you who want to know how long each day really is:
ftp://hpiers.obspm.fr/iers/bul/bulb_new/bulletinb.dat
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
--
WBW,
V.P.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/
mailman/listinfo/time-nuts
and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Hello,
As I am in the process of creation of my own Nixie clocks. And it
probably good time frame to clarify one thing about leap seconds. In my
project I am using GPS module as an option to have current UTC time and
also to have 1PPS signal to do auto-adjustment for external RTC module.
The question is how usually GPS modules handle leap seconds ? Is it
satelates who send UTC time to GPS module or GPS module has firmware
with leap second information hard-coded ?
The same question is for UNIX epoch time. How computers knows if it is
necessary to add leap seconds ? Lets say I am using very simple script
to calculate UNIX time for specified date:
#!/usr/bin/perl
use Time::Local;
my ($d, $m, $y);
my $time;
@myYears = ('01/06/2000', '01/06/2015', '01/06/2038', '01/06/3000');
foreach (@myYears) {
($d, $m, $y) = split '/', $_;
$time = timelocal(0,0,0,$d,$m-1,$y);
printf %ld\n\r, $time;
}
==
It will produce the following output:
959832000
1433131200
2158977600
32516740800
I am not sure if its take leap second consideration. Most likely not.
And that means its only accurate for the present and pas time. Right ?
For my clock I already implement the function for the leap second and I
am able to add/remove number of seconds from the time I receiving from
GPS or any other source. But it will be more inetersting if clock could
do it automagically and shows me that famous 60 number without human
interaction. Any advise for this ? Thanks !
Regards,
V.P.
On , Tom Van Baak wrote:
Just announced: there will be a positive leap second at the end of
June 30 2015 UTC (that's Wednesday July 1st for most of the world).
As usual we time nuts will have a leap second party -- where we
capture and share the magic hh:59:60 display on as many different
clocks and instruments as possible.
/tvb
More info:
ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
http://hpiers.obspm.fr/eop-pc/
And for those of you who want to know how long each day really is:
ftp://hpiers.obspm.fr/iers/bul/bulb_new/bulletinb.dat
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
--
WBW,
V.P.
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Re: [time-nuts] June 30 2015 leap second
Here's a nixie clock using javascript. It includes a leap second count down
which is now active:
http://leapsecond.com/java/nixie.htm
For your project, any GPS module with 1PPS output is a start. Those with NMEA
output are problematic. First, there is no advanced notice that a leap second
is pending in standard NMEA sentences. Second, some GPS receivers cheat and
output a double 23:59:59 or a double 00:00:00 instead of a true 23:59:60 for a
positive leap second. Third, the NMEA timestamp follows the 1PPS instead of
leads so you only find out too late that there was a leap second.
To get it right, you'll need two external switches that the user can flip to
indicate that a leap second should be applied at the end of the current
calendar month and what sign the leap second is (insert or delete). The state
should be reset after the leap second to avoid an accidental leap second the
next day or next month. This is what modern atomic clocks like the hp 5071A or
FTS 4065B do.
Better GPS receivers, like Oncore, M12, TBolt, and ublox provide a binary
interface and from this you get the leap second warning bits without resorting
to switches. This is the preferred automagic solution.
Note also that leap seconds are applied at UTC midnight, so if your Nixie clock
displays local time, including daylight saving time, you have to take this into
account. For me the local leap second is 15:59:60 PST or 16:59:60 PDT.
The UNIX epoch time and leap seconds is a can of worms. It's best to think of
time_t as a vintage, convenient, compact, binary integer encoding to/from a
readable, portable, ascii string -mm-dd hh:mm:ss that works most of the
time except when it doesn't. Your perl script will work, except for leap
seconds.
All the external RTC modules I've seen are incompatible with leap seconds. The
same is true for any analog clock display (wrist watches, wall clocks).
Big Ben handles leap seconds by adjusting the pendulum rate by an equivalent of
12 ppm a day before the leap. Google handles leap seconds in a similar way:
http://news.bbc.co.uk/2/hi/science/nature/7792436.stm
http://googleblog.blogspot.com/2011/09/time-technology-and-leaping-seconds.html
Most computers don't know if there will be a leap second (and don't care). If
you run NTP you get some low level support for leap seconds, but even still
most UNIX and Windows software is incapable of displaying or parsing the
23:59:60 leap second correctly.
/tvb
- Original Message -
From: d0ct0r t...@patoka.org
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Tuesday, January 06, 2015 1:01 PM
Subject: Re: [time-nuts] June 30 2015 leap second
Hello,
As I am in the process of creation of my own Nixie clocks. And it
probably good time frame to clarify one thing about leap seconds. In my
project I am using GPS module as an option to have current UTC time and
also to have 1PPS signal to do auto-adjustment for external RTC module.
The question is how usually GPS modules handle leap seconds ? Is it
satelates who send UTC time to GPS module or GPS module has firmware
with leap second information hard-coded ?
The same question is for UNIX epoch time. How computers knows if it is
necessary to add leap seconds ? Lets say I am using very simple script
to calculate UNIX time for specified date:
#!/usr/bin/perl
use Time::Local;
my ($d, $m, $y);
my $time;
@myYears = ('01/06/2000', '01/06/2015', '01/06/2038', '01/06/3000');
foreach (@myYears) {
($d, $m, $y) = split '/', $_;
$time = timelocal(0,0,0,$d,$m-1,$y);
printf %ld\n\r, $time;
}
==
It will produce the following output:
959832000
1433131200
2158977600
32516740800
I am not sure if its take leap second consideration. Most likely not.
And that means its only accurate for the present and pas time. Right ?
For my clock I already implement the function for the leap second and I
am able to add/remove number of seconds from the time I receiving from
GPS or any other source. But it will be more inetersting if clock could
do it automagically and shows me that famous 60 number without human
interaction. Any advise for this ? Thanks !
Regards,
V.P.
On , Tom Van Baak wrote:
Just announced: there will be a positive leap second at the end of
June 30 2015 UTC (that's Wednesday July 1st for most of the world).
As usual we time nuts will have a leap second party -- where we
capture and share the magic hh:59:60 display on as many different
clocks and instruments as possible.
/tvb
More info:
ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat
http://hpiers.obspm.fr/eop-pc/
And for those of you who want to know how long each day really is:
ftp://hpiers.obspm.fr/iers/bul/bulb_new/bulletinb.dat
Re: [time-nuts] June 30 2015 leap second
On 7 Jan 2015 00:23, d0ct0r t...@patoka.org wrote: Hello, The same question is for UNIX epoch time. How computers knows if it is necessary to add leap seconds ? During the event, the kernel raw time (assuming UTC) will go from 23:59:58.9 straight to 00:00:00.0 when removing a leap second, and when inserting one, Linux for example will go 23:59:59.9 to 23:59:59.0 again. The time formatting library functions (aware of leap and time zones) will turn the latter into xx:59:60. As to how the computer knows - some time sync software (NTPd, PTPd etc.), which is made aware of the event from upstream, needs to tell the kernel about this - on systems with the kernel NTP API like Linux, BSDs and others, this is done by setting a respective STA_INS or STA_DEL status flag with ntp_adjtime() or adjtimex(). This can be done in kernel up to 24 hours in advance. When either of the two flags is set, the kernel will trigger the leap event in the last seconds of the current day. GPS should announce the pending leap second not long after the IERS announcement. I haven't checked my clocks yet but it may already be out there. ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
[time-nuts] June 30 2015 leap second
Just announced: there will be a positive leap second at the end of June 30 2015 UTC (that's Wednesday July 1st for most of the world). As usual we time nuts will have a leap second party -- where we capture and share the magic hh:59:60 display on as many different clocks and instruments as possible. /tvb More info: ftp://hpiers.obspm.fr/iers/bul/bulc/bulletinc.dat http://hpiers.obspm.fr/eop-pc/ And for those of you who want to know how long each day really is: ftp://hpiers.obspm.fr/iers/bul/bulb_new/bulletinb.dat ___ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
