[ntp:questions] Leap second smearing test results
Folks, I've run some tests with smearing of leap seconds. If you're interested, you can find the results here: https://www.meinberg.de/download/burnicki/ntp_leap_smearing_test_results.pdf Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second resources
As of today UTC, ntpq -crv should now be reporting something like: associd=0 status=4419 leap_add_sec, sync_uhf_radio, 1 event, leap_armed, version=ntpd 4.2.6p5@1.2349-o Jul 30 11:55:08 (UTC+02:00) 2012 (2), processor=x86, system=Windows, leap=01, stratum=1, precision=-21, ... If it is not, your system may not handle the leap second correctly. -- Take care. Thanks, Brian Inglis On 2015-06-05 03:40, Marco Marongiu wrote: On 05/06/15 10:59, Miroslav Lichvar wrote: On Thu, Jun 04, 2015 at 05:52:47PM +0200, Marco Marongiu wrote: As you may have noticed from my messages in this list, I've also been running leap second simulations with ntpd on Debian during the past few weeks. If you're using Debian Linux systems you may find the post I've just published useful: http://syslog.me/2015/06/04/a-humble-attempt-to-work-around-the-leap-second-2015-edition/ That is an interesting idea to use -x on both server and client. Does it make the leap second correction easier for the clients to follow and reduce the offset between them? First and foremost, it doesn't allow them to step. Which they may do, since (as you have seen), their offset from the server may grow more than tolerable. And they will receive the leap warning nonetheless. Maybe I'm overcautious, but... better safe than sorry. In your offset plot there are two large (~0.5 second) swings. It doesn't look like the client is fast enough to follow that, but maybe the course of the correction is less variable? I'm still experimenting a lot to collect a fair amount of cases. That image comes from a simulation where the client was configured to use only one server but with a reduced maxpoll (7 instead of 10). In the latest simulation I ran between yesterday and today I had only one client polling three servers with maxpoll 8, and the curve is definitely better: https://twitter.com/brontolinux/status/606723588427776000 https://pbs.twimg.com/media/CGuDi6nVAAAie4q.png:large The servers themselves were following three stepping upstreams and didn't manage to stay very close in the beginning, but ntpd on the clients will take care of that: https://pbs.twimg.com/media/CGuDhfRUgAAdLL_.png:large In my tests when only clients were using -x I saw offsets between them up to 0.8 seconds when one client overshoot a lot and the other didn't. That's a possibility, unfortunately. That's why I'm using a reduced maxpoll on the clients to try to reduce spikes and convergence time as much as possible. Our clients use only our servers, so that we don't obsess public sources while reducing maxpoll. I would never do that against public sources. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap Second on NTP server at stratum 2
On 06/11/2015 08:41 AM, Kashif Mumtaz Tahir wrote: Dear Jochen, You extracted description is right , we are at stratum 2 and just syncing its time with stratum 1 level GPS device. Litte bit confused with your conclusion. When leap second will happen on GPS what will the impact on our stratum 2 level server and below beyond ( Straum 3 client etc ) The part I cannot answer is whether (and when) the GPS device will forward the information about the upcoming leap second into the data it hands out via NTP. As an example, Meinberg states that their GPS receivers will start announcing the leap second during the last 59 minutes: https://www.meinbergglobal.com/english/info/leap-second.htm#refclocks and confirms that those units which also speak NTP will include the refclock's announcement in their replies: https://www.meinbergglobal.com/english/info/leap-second.htm#ntp-server So, *if* your GPS unit were a Meinberg LANTIME model, your stratum 2 server would be made aware of the upcoming leap second about one hour before it happens. Now, assuming that that *does* happen: ntpd *does* forward this information (because you have no leapsecond files overriding the info received from the server), and ntpds actually start polling their servers more frequently as the leap second slot draws near, so all devices running NTP (not SNTP) will typically have their OS armed (informed that it - the OS, not ntpd - will have to take action to conform to the leap second) in time. That implies that *how* they actually do that is up to every OSes' choices and implementation. The most usual *choice* is to have the OS clock stepped back one second, 23:59:59.999... - 23:59:59.000... . And then there's the possibility that the code, which currently gets executed once every couple *years*, has a bug making it do *something else*. For (a historic) example, freeze the server. :-/ That's why having test machines go through a simulated leap second is a thing. (For sake of completeness, any client doing SNTP will notice a one-second offset the first time it contacts its servers after the leap second, and perform the step *then*. That should IIUC (still) include most of the machines running Windows.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap Second on NTP server at stratum 2
Dear Jochen, You extracted description is right , we are at stratum 2 and just syncing its time with stratum 1 level GPS device. Litte bit confused with your conclusion. When leap second will happen on GPS what will the impact on our stratum 2 level server and below beyond ( Straum 3 client etc ) Regards, kashif -Original Message- From: Jochen Bern [mailto:jochen.b...@linworks.de] Sent: Wednesday, June 10, 2015 6:43 PM To: Kashif Mumtaz Tahir Cc: questions@lists.ntp.org Subject: Re: Re: [ntp:questions] Leap Second on NTP server at stratum 2 On 06/10/2015 01:27 PM, Kashif Mumtaz Tahir wrote: Dear Macro, We just want to sync seamless with leap seconds. [...] Should we need to change/tune anything. I read your description as: -- There is a GPS device that actually *speaks NTP* (as opposed to, e.g., being connected to a server with a serial cable) -- This device feeds a central stratum 2 server running ntpd -- Everything else of interest is an NTP (not SNTP) client of that central server -- No special configs beyond the above, in particular, -- no additional external NTP servers, -- no leap seconds file, and -- no suppression of stepping configured on any of the machines. My conclusions: -- Whatever announcement the GPS unit makes of the upcoming leap second will be forwarded to the various machines. -- You hopefully have historic records, vendor statements, or whatever indicating that this GPS unit *will* announce a leap second to be *inserted*. (It mistakenly announcing a *negative* leap should be highly improbable, but I have no idea how likely it is to find a GPS unit that flat out doesn't propagate leap second announcements.) -- The job of actually executing the leap second will be left to the OS kernel of every individual machine - if you cannot afford them hitting a historic or new bug that night, you should start testing kernel versions with simulated leap seconds ASAP. -- There is a (very small) chance that in the leap second night, your single-point-of-failure GPS unit will somehow cease to work before any announcement happens and your platform will never learn of the upcoming leap second - in which case you'll find it working but being offset by one second in the morning. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Leap Second on NTP server at stratum 2
Dear Folks, Our NTP server is placed at stratum 2 which is syncing its time with uplink GPS devices ( Which are on stratum 1 ). Now question is that on June 30th leap second is going to happen, is there anything we need to change /modify on our startum 2 NTP server and other clients of stratum 2 server which are syncing its time with our Stratum 2 server regarding this. Regards, Kashif ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap Second on NTP server at stratum 2
On 10/06/15 13:02, Kashif Mumtaz Tahir wrote: is there anything we need to change /modify It depends on what you want to achieve. I am upgrading to 4.2.8p3 and setting tinker step 0 and disable kernel in the configuration because I am trying to avoid clock stepping at all cost. What about you? -- M ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap Second on NTP server at stratum 2
Dear Macro, We just want to sync seamless with leap seconds.We are at straum 2 level. Should we need to change/tune anything. Regards, -Original Message- From: questions [mailto:questions-bounces+ktahir=ies.etisalat...@lists.ntp.org] On Behalf Of Marco Marongiu Sent: Wednesday, June 10, 2015 3:14 PM To: questions@lists.ntp.org Subject: Re: [ntp:questions] Leap Second on NTP server at stratum 2 On 10/06/15 13:02, Kashif Mumtaz Tahir wrote: is there anything we need to change /modify It depends on what you want to achieve. I am upgrading to 4.2.8p3 and setting tinker step 0 and disable kernel in the configuration because I am trying to avoid clock stepping at all cost. What about you? -- M ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap Second on NTP server at stratum 2
On 06/10/2015 01:27 PM, Kashif Mumtaz Tahir wrote: Dear Macro, We just want to sync seamless with leap seconds. [...] Should we need to change/tune anything. I read your description as: -- There is a GPS device that actually *speaks NTP* (as opposed to, e.g., being connected to a server with a serial cable) -- This device feeds a central stratum 2 server running ntpd -- Everything else of interest is an NTP (not SNTP) client of that central server -- No special configs beyond the above, in particular, -- no additional external NTP servers, -- no leap seconds file, and -- no suppression of stepping configured on any of the machines. My conclusions: -- Whatever announcement the GPS unit makes of the upcoming leap second will be forwarded to the various machines. -- You hopefully have historic records, vendor statements, or whatever indicating that this GPS unit *will* announce a leap second to be *inserted*. (It mistakenly announcing a *negative* leap should be highly improbable, but I have no idea how likely it is to find a GPS unit that flat out doesn't propagate leap second announcements.) -- The job of actually executing the leap second will be left to the OS kernel of every individual machine - if you cannot afford them hitting a historic or new bug that night, you should start testing kernel versions with simulated leap seconds ASAP. -- There is a (very small) chance that in the leap second night, your single-point-of-failure GPS unit will somehow cease to work before any announcement happens and your platform will never learn of the upcoming leap second - in which case you'll find it working but being offset by one second in the morning. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second resources
On Thu, Jun 04, 2015 at 05:52:47PM +0200, Marco Marongiu wrote: As you may have noticed from my messages in this list, I've also been running leap second simulations with ntpd on Debian during the past few weeks. If you're using Debian Linux systems you may find the post I've just published useful: http://syslog.me/2015/06/04/a-humble-attempt-to-work-around-the-leap-second-2015-edition/ That is an interesting idea to use -x on both server and client. Does it make the leap second correction easier for the clients to follow and reduce the offset between them? In your offset plot there are two large (~0.5 second) swings. It doesn't look like the client is fast enough to follow that, but maybe the course of the correction is less variable? In my tests when only clients were using -x I saw offsets between them up to 0.8 seconds when one client overshoot a lot and the other didn't. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Leap second resources
Hi there Miroslav Lichvar, whom you have read several times in this list, has put together a very nice set of five possible ways to handle the leap second with both ntpd and chrony. http://developerblog.redhat.com/2015/06/01/five-different-ways-handle-leap-seconds-ntp/ As you may have noticed from my messages in this list, I've also been running leap second simulations with ntpd on Debian during the past few weeks. If you're using Debian Linux systems you may find the post I've just published useful: http://syslog.me/2015/06/04/a-humble-attempt-to-work-around-the-leap-second-2015-edition/ In case you want to run simulations yourselves, you may also find my leap lab toolbox useful. It's now on github: https://github.com/brontolinux/leaplab-tools Enjoy! Ciao -- bronto ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second configuration with 4.2.2p1
Oh, Jeez. I mean 4.2.2p1. Sorry for confusion. Check your vendor docs: https://access.redhat.com/articles/15145 I'm afraid it contains no relevant information. (Except that my kernels can freeze.)-: https://access.redhat.com/articles/199563 or upgrade RHEL or ntp package to current releases to fix issues. As I wrote earlier RHEL upgrade is not an option. These hosts I write about are part of two 4 years old HP supercomputer clusters. HP does not allow us to change the OS. This is due to Ibrix file server issues. You may need to build ntp from source if you can not upgrade RHEL or ntp. You need a support account to see other articles and patches. I think the cheapest solution is cease public NTP service on these hosts two hours before leap second until I check if everything is normal. It is better to say nothing to the clients rather than sending false information. Gabor ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second info in ntp-4.2.4p4
Mohan Kannekanti writes: Hi, We are currently using ntpd version 4.2.4p4. Please see http://support.ntp.org/bin/view/Dev/ReleaseTimeline and understand your choice. You are running software that was released in December of 2006, and was EOL'd in December of 2009 with 4.2.6, which fixed between 630-1000 issues. 4.2.6 was EOL'd in December of 2014 by the release of 4.2.8, which fixed over 1,100 issues. As Leap second insertion is very close, we are trying to be safe from it. here are few questions, - Is 4.2.4p4 capable of receiving Leap Second information from NTP servers?? Yes. Below is our configuration. server time.nist.gov maxpoll 10 minpoll 6 disable monitor restrict default noquery restrict -6 default noquery - Is there any way that I can test whether the current version is providing of Leap Second?? - Are there any configuration changes required?? Required, no. Useful, almost certainly. For example, you could keep an updated leapseconds file on your server and refer to that in your config file. Have you tested your kernels to make sure they can handle a leap second? What about how your client machines will behave during the leap second? - If our version is not good for handling leap second, 1. What will be closest version to upgrade from 4.2.4p4.?? or Why would you *not* want to run the latest release of NTP? 2. Any patches that we can apply to make 4.2.4p4 safe.?? Perhaps, but you'd have to: - look at somewhere between 1,700 and 2,100 patches - decide which ones you wanted - apply and test the patches I'd also recommend your company (and EVERYBODY else who cares about network time) join the NTP Consortium at Network Time Foundation now: http://nwtime.org/membership/why-join/ The bind-9 tarball is about 8MB. The ntp tarball is about 6.5MB. We don't have even 5% of the resources to develop and maintain NTP that ISC has to develop and maintain BIND. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second info in ntp-4.2.4p4
Hi Harlan, Thanks for the information. I understand your points. I'm *only* trying to be get leap second fixes at the moment as we don't have much time to test the new ntpd feature across all our platforms. Yes, I'm testing the kernels too. Also, I'll definitely encourage our folks to be part of NTP Consortium. Thanks, Mohan. On 06/02/2015 11:05 AM, Harlan Stenn wrote: Mohan Kannekanti writes: Hi, We are currently using ntpd version 4.2.4p4. Please see http://support.ntp.org/bin/view/Dev/ReleaseTimeline and understand your choice. You are running software that was released in December of 2006, and was EOL'd in December of 2009 with 4.2.6, which fixed between 630-1000 issues. 4.2.6 was EOL'd in December of 2014 by the release of 4.2.8, which fixed over 1,100 issues. As Leap second insertion is very close, we are trying to be safe from it. here are few questions, - Is 4.2.4p4 capable of receiving Leap Second information from NTP servers?? Yes. Below is our configuration. server time.nist.gov maxpoll 10 minpoll 6 disable monitor restrict default noquery restrict -6 default noquery - Is there any way that I can test whether the current version is providing of Leap Second?? - Are there any configuration changes required?? Required, no. Useful, almost certainly. For example, you could keep an updated leapseconds file on your server and refer to that in your config file. Have you tested your kernels to make sure they can handle a leap second? What about how your client machines will behave during the leap second? - If our version is not good for handling leap second, 1. What will be closest version to upgrade from 4.2.4p4.?? or Why would you *not* want to run the latest release of NTP? 2. Any patches that we can apply to make 4.2.4p4 safe.?? Perhaps, but you'd have to: - look at somewhere between 1,700 and 2,100 patches - decide which ones you wanted - apply and test the patches I'd also recommend your company (and EVERYBODY else who cares about network time) join the NTP Consortium at Network Time Foundation now: http://nwtime.org/membership/why-join/ The bind-9 tarball is about 8MB. The ntp tarball is about 6.5MB. We don't have even 5% of the resources to develop and maintain NTP that ISC has to develop and maintain BIND. -- This electronic message, including attachments, is intended only for the use of the individual or company named above or to which it is addressed. The information contained in this message shall be considered confidential and proprietary, and may include confidential work product. If you are not the intended recipient, please be aware that any unauthorized use, dissemination, distribution or copying of this message is strictly prohibited. If you have received this email in error, please notify the sender by replying to this message and deleting this email immediately. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second configuration with 4.2.2p1 (Was 4.2.6p5)
I've several old RHEL5 hosts in the NTP Pool with ntpd version 4.2.6p5. Oh, Jeez. I mean 4.2.2p1. Sorry for confusion. Gabor ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second configuration with 4.2.2p1 (Was 4.2.6p5)
On 2015-06-01 07:41, Kiss Gábor wrote: I've several old RHEL5 hosts in the NTP Pool with ntpd version 4.2.6p5. Oh, Jeez. I mean 4.2.2p1. Sorry for confusion. Check your vendor docs: https://access.redhat.com/articles/15145 https://access.redhat.com/articles/199563 or upgrade RHEL or ntp package to current releases to fix issues. You may need to build ntp from source if you can not upgrade RHEL or ntp. You need a support account to see other articles and patches. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second configuration with 4.2.2p1 (Was 4.2.6p5)
=?ISO-8859-15?Q?Kiss_G=E1bor?= writes: I've several old RHEL5 hosts in the NTP Pool with ntpd version 4.2.6p5. Oh, Jeez. I mean 4.2.2p1. Sorry for confusion. http://support.ntp.org/bin/view/Dev/ReleaseTimeline We've only fixed 2,600-3,000 issues in the 4 releases of NTP since 4.2.2 was released in the summer of 2006. There is a point in there somewhere. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Leap second configuration with 4.2.6p5
Dear folks, I've several old RHEL5 hosts in the NTP Pool with ntpd version 4.2.6p5. I try to manage the leap second coming at end of June but I have partial success only. Now ntpd at least finds the leap-seconds.3629404800 file but I guess it gets confused: $ ntpq -c rv 0 leap,tai,leapsec,expire my_server leap=00, expire=201505281348, leapsec=20150105, tai=35 $ The expire value is the minute of restarting ntpd, and the leapsec was at 5th of January. Relevant configuration: keysdir /etc/ntp crypto pw a_password $ ls -l /etc/ntp -rw-r- 1 root ntp 84 Sep 30 2011 keys -rw-r--r-- 2 root root 10384 Apr 10 10:48 leap-seconds.3629404800 lrwxrwxrwx 1 root root58 May 28 15:40 ntpkey_cert_my_server - ntpkey_RSA-MD5cert_my_server.3641809254 lrwxrwxrwx 1 root root53 May 28 15:40 ntpkey_host_my_server - ntpkey_RSAkey_my_server.3641809254 lrwxrwxrwx 1 root root23 May 28 15:32 ntpkey_leap - leap-seconds.3629404800 -rw-r--r-- 1 root root 639 May 28 15:40 ntpkey_RSAkey_my_server.3641809254 -rw-r--r-- 1 root root 626 May 28 15:40 ntpkey_RSA-MD5cert_my_server.3641809254 -rw-r--r-- 1 root root 186 Feb 3 2009 ntpservers -rw-r--r-- 1 root root 0 Nov 26 2009 step-tickers $ grep -v '^#' /etc/ntp/ntpkey_leap | tail -5 3124137600 32 # 1 Jan 1999 3345062400 33 # 1 Jan 2006 3439756800 34 # 1 Jan 2009 3550089600 35 # 1 Jul 2012 3644697600 36 # 1 Jul 2015 Could you suggest what can I try yet? Thanks Gabor ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leap second warning bits in practice
On Tue, May 12, 2015 at 11:33:31AM +0200, Marco Marongiu wrote: On 12/05/15 11:28, Marco Marongiu wrote: Hi there In http://doc.ntp.org/4.2.6p5/ntpd.html#leap I read: If the leap is in the future less than 28 days, the leap warning bits are set. What are the practical consequences of the warning bits being set? Will they cause the leap second to be armed in the kernel eventually? What if the kernel discipline is disabled? To be a bit clearer, further down it says When a majority of the survivors show warning, a leap is programmed at the end of the current month. What does that programmed stand for...? I think it means setting of the leap status that's reported in NTP packets and if the kernel discipline is enabled it also sets the kernel leap status bits. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leap second warning bits in practice
On 13/05/15 13:23, Miroslav Lichvar wrote: I'm not sure what exactly are you asking here. Do you see in your testing or the source code something different from what is described in the document? No, I am trying to understand if what I understand* from the documentation is correct. * sorry for the repetition ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leap second warning bits in practice
On 13/05/15 11:03, Miroslav Lichvar wrote: On Tue, May 12, 2015 at 11:33:31AM +0200, Marco Marongiu wrote: On 12/05/15 11:28, Marco Marongiu wrote: Hi there In http://doc.ntp.org/4.2.6p5/ntpd.html#leap I read: If the leap is in the future less than 28 days, the leap warning bits are set. What are the practical consequences of the warning bits being set? Will they cause the leap second to be armed in the kernel eventually? What if the kernel discipline is disabled? To be a bit clearer, further down it says When a majority of the survivors show warning, a leap is programmed at the end of the current month. What does that programmed stand for...? I think it means setting of the leap status that's reported in NTP packets and if the kernel discipline is enabled it also sets the kernel leap status bits. Thanks for your answer Miroslav I don't think it's the case. In the linked doc, the sentence right after the quoted one says: If in the future less than 23 hours, the kernel is armed to insert one second at the end of the current day I understand that the leap second is not armed in the kernel if only the warning is set. Rather, it seems that the warning is used by a client to understand if it should believe its upstreams when they claim there will be a leap second by this month. I think my interpretation is correct but I'd really appreciate if someone could either confirm or clarify, so that I/we know exactly what to expect. Thanks -- bronto ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leap second warning bits in practice
On Wed, May 13, 2015 at 11:44:37AM +0200, Marco Marongiu wrote: I understand that the leap second is not armed in the kernel if only the warning is set. Rather, it seems that the warning is used by a client to understand if it should believe its upstreams when they claim there will be a leap second by this month. I think my interpretation is correct but I'd really appreciate if someone could either confirm or clarify, so that I/we know exactly what to expect. I'm not sure what exactly are you asking here. Do you see in your testing or the source code something different from what is described in the document? -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] leap second warning bits in practice
Hi there In http://doc.ntp.org/4.2.6p5/ntpd.html#leap I read: If the leap is in the future less than 28 days, the leap warning bits are set. What are the practical consequences of the warning bits being set? Will they cause the leap second to be armed in the kernel eventually? What if the kernel discipline is disabled? Thanks, ciao -- bronto ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] leap second warning bits in practice
On 12/05/15 11:28, Marco Marongiu wrote: Hi there In http://doc.ntp.org/4.2.6p5/ntpd.html#leap I read: If the leap is in the future less than 28 days, the leap warning bits are set. What are the practical consequences of the warning bits being set? Will they cause the leap second to be armed in the kernel eventually? What if the kernel discipline is disabled? To be a bit clearer, further down it says When a majority of the survivors show warning, a leap is programmed at the end of the current month. What does that programmed stand for...? Ciao -- bronto ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap-second test with ntpd
On Feb 23, 2015, at 4:37 PM, Harlan Stenn st...@ntp.org wrote: You might not need orphan mode at all - just the plain local refclock driver. You might also just need a customized leapseconds file. Yeah, that was my first test — just: server 127.127.1.1 minpoll 4 maxpoll 5 fudge 127.127.1.1 stratum 4 leapfile /etc/ntp/leap-seconds.list The documentation[1] says that “orphan mode” is the replacement for the local clock, so that’s why I tried that too. (It also says that since 4.2.5p101 ntpd can run in “pure orphan mode”, so that’s why I tried it that way, too). Ask [1] http://support.ntp.org/bin/view/Support/OrphanMode ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap-second test with ntpd
On Feb 23, 2015, at 6:38 PM, Ask Bjørn Hansen a...@develooper.com wrote: On Feb 23, 2015, at 4:37 PM, Harlan Stenn st...@ntp.org wrote: You might not need orphan mode at all - just the plain local refclock driver. You might also just need a customized leapseconds file. Yeah, that was my first test — just: server 127.127.1.1 minpoll 4 maxpoll 5 fudge 127.127.1.1 stratum 4 leapfile /etc/ntp/leap-seconds.list” Oh, what do you know — now that works, maybe I just didn’t wait long enough last time! So in summary: local clock seems to work; I didn’t see any signs of orphan mode working at all. Ask ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap-second test with ntpd
On 02/24/2015 01:23 AM, Ask Bjørn Hansen wrote: I am trying to setup an ntpd to use the local clock as the reference source and so I can set the time to late June and verify 1) what ntpd does and 2) what clients do. FYI, I researched the question of how to simulate an upcoming leap second (as announced through NTP) a while back, and the solution I have in the drawer (still waiting for the next firmware release to go into QA) is to set up a dedicated (phony) NTP server with NTP-Proxy. https://github.com/AmadeusITGroup/NTP-Proxy#indirect-ls-simulation-via-ntp Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap-second test with ntpd
Ask Bjørn Hansen wrote: On Feb 23, 2015, at 4:37 PM, Harlan Stenn st...@ntp.org wrote: You might not need orphan mode at all - just the plain local refclock driver. You might also just need a customized leapseconds file. Yeah, that was my first test — just: server 127.127.1.1 minpoll 4 maxpoll 5 fudge 127.127.1.1 stratum 4 leapfile /etc/ntp/leap-seconds.list Hm, alternatively you may use the first instance of the local clock, 127.127.1.0. I don't think this matters, though. ;-) I've just run a few tests with such setup and ntpd 4.2.6p5 vs. 4.2.8p1. Set the current system time close enough before the leap time, which may be some ( less than 24) hours, or just 10 minute. Then start ntpd. With 4.2.6p5: The local clock becomes system peer immediately after startup, and leap bits are also set to 01 immediately. This is very nice for leap second testing, but letting local clock become system peer immediately causes some drawbacks in normal operation. With 4.2.8p1: The local clock becomes system peer only quite some time (about 300 seconds) after ntpd has been started, and another 7 seconds after this the leap bits are changed to 01. I'm not sure where the ~300 s come from since they vary slightly with the polling interval configured for the local clock: With minpoll 3 or 4 local clock becomes system peer @305 s after startup With minpoll 5 or 6 local clock becomes system peer @321 s after startup In any case the testing works if you wait until local clock becomes system peer. An alternate way is to fudge the local clock to flag1 1 which lets the local clock provide ntpd with a leap second warning, even without using a leap second file. This works with both 4.2.6p5 and 4.2.8p1. However, while ntpd's system leap flags go back to 00 after the leap second the local clock's leap flags stay at 01, so if you let the ntpd running after the initial test it will probably insert another leap second at the end of each month (not tested). The documentation[1] says that “orphan mode” is the replacement for the local clock, so that’s why I tried that too. (It also says that since 4.2.5p101 ntpd can run in “pure orphan mode”, so that’s why I tried it that way, too). I've not yet tested orphan mode. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap-second test with ntpd
Ask Bj?rn Hansen writes: On Feb 23, 2015, at 4:37 PM, Harlan Stenn st...@ntp.org wrote: You might not need orphan mode at all - just the plain local refclock driver. You might also just need a customized leapseconds file. Yeah, that was my first test =E2=80=94 just: server 127.127.1.1 minpoll 4 maxpoll 5 fudge 127.127.1.1 stratum 4 leapfile /etc/ntp/leap-seconds.list The documentation[1] says that =E2=80=9Corphan mode=E2=80=9D is the = replacement for the local clock, so that=E2=80=99s why I tried that too. = (It also says that since 4.2.5p101 ntpd can run in =E2=80=9Cpure orphan = mode=E2=80=9D, so that=E2=80=99s why I tried it that way, too). [1] http://support.ntp.org/bin/view/Support/OrphanMode OK, first, in general, most folks want Orphan Mode. There are *very few* cases where one wants a local refclock. This may or may not be one of them. I am *pretty sure* that it doesn't matter which one you use. The key element is probably that you have a leapfile on your box that says when you want the leap to happen, and you set the time on this box with no external servers. In this case, with either orphan mode or with a local refclock, the local machine should offer sync'd time at whatever stratum is selected. Please pick something so if somebody stumbles across this machine it won't be believed. H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Leap-second test with ntpd
Hi everyone, I am trying to setup an ntpd to use the local clock as the reference source and so I can set the time to late June and verify 1) what ntpd does and 2) what clients do. I had it working with the 4.2.4 that comes with FreeBSD 10.1 (and the local clock), but I wanted to use 4.2.8 since that's what is supported (and because of the better, I think, support for the leap second list file). With 4.2.4 then I could configure ntpd with this and it'd serve time to clients: server 127.127.1.1 minpoll 4 maxpoll 5 fudge 127.127.1.1 stratum 4 WIth 4.2.8 it never thinks it's in sync with that configuration. I've also tried with variations of tos orphan 3 orphanwait 2 and tos orphan plus the local clock. Finally then I've tried adding a bogus server (one that never responds) on a server line in case ntpd really wants to try reaching a real clock before it'll give up and trust the local clock, but I keep getting 127.0.0.1: Server dropped: Server has gone too long without sync from ntpd. What am I missing? Ask faketime# ntpq -c pe -n remote refid st t when poll reach delay offset jitter == 127.127.1.1 .LOCL. 4 l7 16 3770.0000.000 0.000 10.0.200.99 .INIT. 16 u- 3200.0000.000 0.000 faketime# ntpq -c rv assID=0 status=4019 leap_add_sec, sync_unspec, 1 event, event_9, version=ntpd 4.2.8p1@1.3265-o Wed Feb 11 14:52:45 UTC 2015 (1), processor=amd64, system=FreeBSD/10.1-STABLE, leap=01, stratum=3, precision=-24, rootdelay=0.000, rootdisp=0.000, refid=127.0.0.1, reftime=. Thu, Feb 7 2036 6:28:16.000, clock=d93d2598.951cfd78 Tue, Jun 30 2015 14:26:32.582, peer=0, tc=3, mintc=3, offset=0.000, frequency=0.000, sys_jitter=0.00, clk_jitter=0.000, clk_wander=0.000, tai=35, leapsec=20150701, expire=20151228 $ ntpdate -qvd -p 1 faketime.local 23 Feb 16:21:58 ntpdate[94790]: ntpdate 4.2.6@1.2089-o Fri May 28 01:20:57 UTC 2010 (1) Looking for host faketime.local and service ntp host found : 10.0.200.250 transmit(10.0.200.250) receive(10.0.200.250) transmit(10.0.200.250) 10.0.200.250: Server dropped: Server has gone too long without sync server 10.0.200.250, port 123 stratum 3, precision -24, leap 01, trust 000 refid [10.0.200.250], delay 0.02599, dispersion 0.0 transmitted 1, in filter 1 reference time:. Sun, Dec 31 1899 16:00:00.000 originate timestamp: d93d25b5.9dba6981 Tue, Jun 30 2015 7:27:01.616 transmit timestamp: d89642a9.e6ba0620 Mon, Feb 23 2015 16:22:01.901 filter delay: 0.02599 0.0 0.0 0.0 0.0 0.0 0.0 0.0 filter offset: 10937099 0.00 0.00 0.00 0.00 0.00 0.00 0.00 delay 0.02599, dispersion 0.0 offset 10937099.714600 23 Feb 16:22:01 ntpdate[94790]: no server suitable for synchronization found ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap-second test with ntpd
On 2015-02-23 17:23, Ask Bjørn Hansen wrote: I am trying to setup an ntpd to use the local clock as the reference source and so I can set the time to late June and verify 1) what ntpd does and 2) what clients do. I had it working with the 4.2.4 that comes with FreeBSD 10.1 (and the local clock), but I wanted to use 4.2.8 since that's what is supported (and because of the better, I think, support for the leap second list file). With 4.2.4 then I could configure ntpd with this and it'd serve time to clients: server 127.127.1.1 minpoll 4 maxpoll 5 fudge 127.127.1.1 stratum 4 WIth 4.2.8 it never thinks it's in sync with that configuration. I've also tried with variations of tos orphan 3 orphanwait 2 and tos orphan plus the local clock. Finally then I've tried adding a bogus server (one that never responds) on a server line in case ntpd really wants to try reaching a real clock before it'll give up and trust the local clock, but I keep getting 127.0.0.1: Server dropped: Server has gone too long without sync from ntpd. What am I missing? IIRC recent releases mark LCL unselectable if any other sources are configured: so remove other sources. Try adding server option true to force selection; maybe also set fudge time2 to drift rate? If all else fails try dev 4.3.0 and hack ;^ -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap-second test with ntpd
Martin might have a good answer for you. I'd like to see these instructions written up. You might not need orphan mode at all - just the plain local refclock driver. You might also just need a customized leapseconds file. H Ask Bj?rn Hansen writes: Hi everyone, I am trying to setup an ntpd to use the local clock as the reference source and so I can set the time to late June and verify 1) what ntpd does and 2) w hat clients do. I had it working with the 4.2.4 that comes with FreeBSD 10.1 (and the local c lock), but I wanted to use 4.2.8 since that's what is supported (and because of the better, I think, support for the leap second list file). With 4.2.4 then I could configure ntpd with this and it'd serve time to clien ts: server 127.127.1.1 minpoll 4 maxpoll 5 fudge 127.127.1.1 stratum 4 WIth 4.2.8 it never thinks it's in sync with that configuration. I've also tried with variations of tos orphan 3 orphanwait 2 and tos orphan plus the local clock. Finally then I've tried adding a bogus server (one that never responds) on a server line in case ntpd really wants to try reaching a real clock before it' ll give up and trust the local clock, but I keep getting 127.0.0.1: Server d ropped: Server has gone too long without sync from ntpd. What am I missing? Ask faketime# ntpq -c pe -n remote refid st t when poll reach delay offset jitte r = = 127.127.1.1 .LOCL. 4 l7 16 3770.0000.000 0.00 0 10.0.200.99 .INIT. 16 u- 3200.0000.000 0.00 0 faketime# ntpq -c rv assID=0 status=4019 leap_add_sec, sync_unspec, 1 event, event_9, version=ntpd 4.2.8p1@1.3265-o Wed Feb 11 14:52:45 UTC 2015 (1), processor=amd64, system=FreeBSD/10.1-STABLE, leap=01, stratum=3, precision=-24, rootdelay=0.000, rootdisp=0.000, refid=127.0.0.1, reftime=. Thu, Feb 7 2036 6:28:16.000, clock=d93d2598.951cfd78 Tue, Jun 30 2015 14:26:32.582, peer=0, tc=3, mintc=3, offset=0.000, frequency=0.000, sys_jitter=0.00, clk_jitter=0.000, clk_wander=0.000, tai=35, leapsec=20150701, expire=20151228 $ ntpdate -qvd -p 1 faketime.local 23 Feb 16:21:58 ntpdate[94790]: ntpdate 4.2.6@1.2089-o Fri May 28 01:20:57 UT C 2010 (1) Looking for host faketime.local and service ntp host found : 10.0.200.250 transmit(10.0.200.250) receive(10.0.200.250) transmit(10.0.200.250) 10.0.200.250: Server dropped: Server has gone too long without sync server 10.0.200.250, port 123 stratum 3, precision -24, leap 01, trust 000 refid [10.0.200.250], delay 0.02599, dispersion 0.0 transmitted 1, in filter 1 reference time:. Sun, Dec 31 1899 16:00:00.000 originate timestamp: d93d25b5.9dba6981 Tue, Jun 30 2015 7:27:01.616 transmit timestamp: d89642a9.e6ba0620 Mon, Feb 23 2015 16:22:01.901 filter delay: 0.02599 0.0 0.0 0.0 0.0 0.0 0.0 0.0 filter offset: 10937099 0.00 0.00 0.00 0.00 0.00 0.00 0.00 delay 0.02599, dispersion 0.0 offset 10937099.714600 23 Feb 16:22:01 ntpdate[94790]: no server suitable for synchronization found ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Ceux qui sont prêts à abandonner une liberté essentielle pour obtenir une petite et provisoire sécurité, ne méritent ni liberté ni sécurité. Benjimin Franklin Le 16 janv. 2015 à 08:42, Harlan Stenn st...@ntp.org a écrit : Terje Mathisen writes: cmad...@cmadams.net (Chris Adams) wrote: Also, you can't properly represent future timestamps (necessary for some things) as seconds since an epoch, and that's pretty widely used. By that I mean that the number of seconds between 2015-06-30 23:59:00 and 2015-07-01 00:00:00 has changed since last month. The General Timestamp API handles this case, as those timestamps track the version number of the timescale. If you specify noon at (some future date), an absolute timestamp, and between now and then some leap seconds are added, they'll be added here, too. How can we take into account an unknown number of leaps? I will listen attentively to your presentation in Bruxelles. I can see how it might be feasible…. But I will have to check with Schrodinger's cat first. And this is _exactly_ why it is always a bad idea to use (UTC) seconds for those future timestamps: If you actually mean that something has to happen N seconds from now, that future timestamp has to be in TAI, since using UTC would obviously blow up across any leap second, right? If one used a relative/difference timestamp for this, then we're in the same boat and we might need some sort of trigger or signal to indicate that a leap event has happened. We're often in a similar boat though, if the clock steps during the interval this relative/difference timestamp covers. This should arguably be an option for cron jobs and timer events. cron is a notoriously bad scheduler. It only wakes up every minute to check the schedule tasks, so you can’t be sure of getting accurate execution times. It am not sure it is relevant either, as events are scheduled in terms of absolute times so will be correct whether or not a leap second is scheduled. Task execution on a callback, interval timer event is different. One scheduled for execution in 5 seconds, 3 seconds prior to a positive leap second will get dispatched 4 TAI seconds later, but from a legal point of view will be dead on. However if that is not already fixed, it could be. H -- If you instead meant a calendar event, then you need a different timescale which is either Julian Day Number (JDN) or YMD, followed by either HMS or an offset into the day, followed by the applicable time zone. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
strange response! Le 11 janv. 2015 à 21:18, Paul tik-...@bodosom.net a écrit : Why do folks mention leap seconds on this list? part of the NTP protocol deals with the scheduling insertion/deletion of leap seconds. Why do people point to leap-seconds.NTPtimestamp instead of just leap-seconds.list? leap-seconds.list is not the file itself, but a symbolic link, which in itself contains no relevant information other than the pathname, in this case relative, to the actual file. The symbolic link leap-seconds.list does not exist on some repositories of the information, for example on the navy server tyco. Using the full timestamped name is also the only way of unambiguously identifying this data. The time stamp differs on different sources. My five line leap second file with comments and one extra line for (completely unnecessary) context. #$ 3629404800 #@ 3660249600 3550089600 35 # 1 Jul 2012 3644697600 36 # 1 Jul 2015 #h 6eb5f274 cb8c4f5d 6ac15b69 6b095017 f219e7c ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Mon, Jan 26, 2015 at 06:45:58PM +0100, Terje Mathisen wrote: Miroslav Lichvar wrote: Here is a test showing error between two clients of a server smearing.a large offset. With the cosine function you can see a large spike when smearing started. https://mlichvar.fedorapeople.org/tmp/smear_cos.png https://mlichvar.fedorapeople.org/tmp/smear_sinx.png This seems wrong!?! First of all, you seem to extend the smearing over a million seconds or so? I.e. 10-15 days? Yes. How large is the adjustment to be smeared out? 1 seconds. It was a test to see how useful is smearing when bringing an isolated network back to UTC in a controlled manner. The google cosine approach starts with a derivate of zero and ends the same way, I really can't see how that leads to that huge (more than 128 ms!) spike at the start? The frequency is changing too quickly at start (2nd derivative is at the maximum) and the clients don't have a chance to shorten their polling interval to better track the server. The point is that there are better functions than cosine for this. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/27/2015 10:16 AM, Terje Mathisen wrote: Jochen Bern wrote: Because they chose the long window (about one day) and made it exceed the time an NTP peering needs to *act* on the perceived offset, yes. If That's a a key feature of the long adjustment period: The smearing takes so long that the frequency offset is never even close to the 500 ppm limit, and (since the first derivative is smooth) the change is frequency is gradual enough that all the clients will be able to track it, even if they are running at a fixed 1024 s polling interval. OK, but that's assuming that the client will absorb the leap second entirely by having an NTP server dragging it along within the limits of a normal NTP sync, without *ever* informing the client kernel's leap second handling routines that one even occurred. Which means that your client cannot be talking to a normal NTP server with normal NTP client s/w, and if kernels ever would attempt to keep track of past leap seconds on their own, *this* client's kernel would fail in that because it never gets *told* of leap seconds as they happen. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern wrote: On 01/26/2015 01:03 PM, Terje Mathisen wrote: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. I noticed that it lends itself to such properties (even if Googles specific implementation fails to do so). However, you pay for it either in a long window needed to perform the smear, on in some of said derivatives going *way* off their normal values. The _huge_ problem with their approach is that they have to make d*** sure there will never be any time leaks between their internal smeared timebase and any external UTC/TAI clocks as long as the adjustment is taking place. Because they chose the long window (about one day) and made it exceed the time an NTP peering needs to *act* on the perceived offset, yes. If That's a a key feature of the long adjustment period: The smearing takes so long that the frequency offset is never even close to the 500 ppm limit, and (since the first derivative is smooth) the change is frequency is gradual enough that all the clients will be able to track it, even if they are running at a fixed 1024 s polling interval. it weren't announced that NTPv5 will support labelling the actual timescale used, I'ld propose that future kernels SHOULD not only accept leap second upcoming bits from an NTP client s/w, but also hand leap second handling in progress bits back, so as to allow the s/w to mark itself as unsynced via NTP until the effects are over. That is already possible, via the leap bits, i.e. declare yourself unsynced if contacted from outside the designated smear region? Terje Regards, J. Bern -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Miroslav Lichvar wrote: On Mon, Jan 26, 2015 at 06:45:58PM +0100, Terje Mathisen wrote: Miroslav Lichvar wrote: Here is a test showing error between two clients of a server smearing.a large offset. With the cosine function you can see a large spike when smearing started. https://mlichvar.fedorapeople.org/tmp/smear_cos.png https://mlichvar.fedorapeople.org/tmp/smear_sinx.png This seems wrong!?! First of all, you seem to extend the smearing over a million seconds or so? I.e. 10-15 days? Yes. How large is the adjustment to be smeared out? 1 seconds. It was a test to see how useful is smearing when bringing an isolated network back to UTC in a controlled manner. 10K seconds in 1M seconds corresponds to a steering rate of 1:100 or 10K ppm, i.e. 20 times higher than the maximum ntpd adjustment rate. How would you expect it to work under those conditions? The google cosine approach starts with a derivate of zero and ends the same way, I really can't see how that leads to that huge (more than 128 ms!) spike at the start? The frequency is changing too quickly at start (2nd derivative is at the maximum) and the clients don't have a chance to shorten their polling interval to better track the server. The point is that there are better functions than cosine for this. OK, when the adjustment is way outside the control range for ntpd, then you are obviously correct: ntpd, either with or without smearing, is not the best tool. :-) Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Terje Mathisen terje.mathi...@tmsw.no writes: The derivatives of sine/cosine are of course +/- cosine/sine, so they stay smooth at all levels. The point is that it is not smooth where it joins on to the regular passage of time... It is possible to do this in an infinitely smooth way, but using the cos formula just gives a few continuous derivatives. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
David Malone wrote: Terje Mathisen terje.mathi...@tmsw.no writes: The derivatives of sine/cosine are of course +/- cosine/sine, so they stay smooth at all levels. The point is that it is not smooth where it joins on to the regular passage of time... It is possible to do this in an infinitely smooth way, but using the cos formula just gives a few continuous derivatives. Mea Culpa. You are of course right. I can even see how using exponential functions with a totally flat tail would allow you to get arbitrarily close to the desired smoothness, but in the real world what we care about is to make the steering something that the normal ntpd control loop handles without breaking a sweat, i.e. in the same magnitude as the usual temperature-induced frequency swings. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern wrote: On 01/27/2015 10:16 AM, Terje Mathisen wrote: Jochen Bern wrote: Because they chose the long window (about one day) and made it exceed the time an NTP peering needs to *act* on the perceived offset, yes. If That's a a key feature of the long adjustment period: The smearing takes so long that the frequency offset is never even close to the 500 ppm limit, and (since the first derivative is smooth) the change is frequency is gradual enough that all the clients will be able to track it, even if they are running at a fixed 1024 s polling interval. OK, but that's assuming that the client will absorb the leap second entirely by having an NTP server dragging it along within the limits of a normal NTP sync, without *ever* informing the client kernel's leap second handling routines that one even occurred. Which means that your client cannot be talking to a normal NTP server with normal NTP client s/w, and if kernels ever would attempt to keep track of past leap seconds on their own, *this* client's kernel would fail in that because it never gets *told* of leap seconds as they happen. That's correct, in all particulars, and as you note, it basically introduces a separate ntp domain for those servers that take part in this charade. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote: The US will soon be considering a means for dissemination of delta T via NTP Does that read there's *several* teams working on NTPv5 and not communicating with each other right now ... ? The ITU has just met in Geneva and discussed the future of leap seconds. The US is in favor of dropping them, the Brits are in favor of keeping the tradition of leap seconds, [...] Leap seconds are an artefact of a) rotation of Earth (which is ever slowing down because of mechanisms that nothing short of pointing a giant disintegrator ray at the Moon can stop, on top of the uncertainty reflected in the unpredictability of current leap seconds), b) the precision we have achieved in measuring - supposedly immutable - physical time, and c) a desire to have time represented in a way that alludes to the traditional apparent position of the Sun right where I stand (on the surface of the Earth) notion. You can quantize and/or distribute leap seconds in a different way, but you can NOT drop them short of kissing one of these three basics goodbye. (If you read through the comments ITU received along with the votes when they put up the poll, you will notice that a great many abolish leap seconds voters proposed schemes that actually do *not* *abolish* the concept of leaps but merely distribute the corrections differently, from infinitesimal leaps to the exceedingly rare leap minute.) Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/22/2015 07:04 PM, William Unruh wrote: General relativity assures us that time exists and is measured by a metric. Take that metric and define a proper time say at the center of the earth. (Bad choice because relativity says that clocks down the gravity well run faster, but we've been ignoring that fact so far, anyway, so ...) [...] while TAI says that difference is .2 sec, UTC says it is 1.2 sec different. That for all purposes is a discontinuous function of the time as defined by General relativity. Now, it is true that UTC does give a name to that second that lies between the two times, but giving it a name does not make the function continous. Actually I agree with that last sentence, but not in the way you expect. It's the *metric* that UTC defines, along with the representation, that makes the function continuous. Basically, UTC not only says that 23:59:60 is valid and shall be ordered between 23:59:59 and 00:00:00, but that it represents one SI second (as measured with any suitable instrument) wherever it is officially inserted. Hence, the difference between 23:59:59.9 UTC and 00:00:00.1 UTC is 0.2 SI seconds wherever a leap second is *not* inserted, and 1.2 SI seconds where it is, *because that's what you were told how to count it*, and since computing the difference between the two UTC timestamps (with a list of past and present leap seconds at hand) correspondingly results in 0.2 UTC seconds or 1.2 UTC seconds unless the timestamps are in the uncertain future, the two notions still agree down to any resolution you want - continuous, linear, derivative with slope = 1. The fact that UTC publishes a list of when those discontinuities occur is also irrelevant. UTC says that leap seconds are part of the UTC representation of time (i.e., on the conversion function's ordinate) and correspond to an actual SI second of physical time that passes (i.e., it's present on the abscissa as well). Your refusing both punches a square hole, one square second large, into the function's graph - that's not a discontinuity in a strict sense, it's a stretch where the function remains undefined by your refusal to acknowledge the definition. Anyone willing to re-insert that square with the diagonal line on it into the graph gets a straight line from one edge of the paper to the other, and has no reason whatsoever to see a discontinuity. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Terje Mathisen terje.mathi...@tmsw.no writes: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. Doesn't it only have two smooth deritives at the end points or [-w:w]? The usual function is constant 1 with all derivatves zero, and so this is what the derivative should be at the endpoints. They use (1.0 - cos(pi * t / w)) / 2.0, which is 1 at both end point, has first derative zero, but the second deritive is -pi*pi/w/w. (It should be possible to stitch together something that is infinitely smooth, probably using exp(-1/(x*x)), but it would requite a bit more work.) David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern wrote: Sorry for the delay, I'm *still* not back to my usual workplace ... On 01/21/2015 11:39 AM, Mike Cook wrote: I couldn’t find a definition of a monotonous function. Does it exist? As David already suggested, I learnt my math in Germany - and switched to CS before taking a shot at a PhD, which would have required me to tear into actual current research, which would have been written in English. So yes, (streng) monoton should have been translated as (strictly) monotonic, not (strictly) monotonous. (Quick terminology recap: A function takes inputs from one set (domain) and assigns an output/result from another set (codomain) to them. In order to define continuous, both domain and codomain need to be ordered and have a notion of distance or difference (metric).) The function can be non-linear. See below. Yes. In particular, implementing a leap second by decelerating your all minutes have 60 seconds clock results in a conversion function that is monotonic and continuous, but not linear. In the case of having it run at half its normal speed for two seconds, it would qualify as piecewise linear - and not have a defined derivative at the switchover points. One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. The _huge_ problem with their approach is that they have to make d*** sure there will never be any time leaks between their internal smeared timebase and any external UTC/TAI clocks as long as the adjustment is taking place. Again, what you are highlighting is the inability or unwillingness of engineers to create sufficiently robust conversion functions. Well, if you want to put it that way, yes. Though unavailability of leap second info within whatever system they're designing (say, a mechanic wrist watch worn by an average human) is a pretty *solid* reason to claim inability to do so. :-) Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Mon, Jan 26, 2015 at 01:03:48PM +0100, Terje Mathisen wrote: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. They could have chosen a better function though. If its second derivative (wander) started at zero, the NTP clients could adjust their polling interval if necessary before the error gets large and the maximum error between the clients could be minimized. Here is a test showing error between two clients of a server smearing.a large offset. With the cosine function you can see a large spike when smearing started. https://mlichvar.fedorapeople.org/tmp/smear_cos.png https://mlichvar.fedorapeople.org/tmp/smear_sinx.png -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/26/2015 01:03 PM, Terje Mathisen wrote: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. I noticed that it lends itself to such properties (even if Googles specific implementation fails to do so). However, you pay for it either in a long window needed to perform the smear, on in some of said derivatives going *way* off their normal values. The _huge_ problem with their approach is that they have to make d*** sure there will never be any time leaks between their internal smeared timebase and any external UTC/TAI clocks as long as the adjustment is taking place. Because they chose the long window (about one day) and made it exceed the time an NTP peering needs to *act* on the perceived offset, yes. If it weren't announced that NTPv5 will support labelling the actual timescale used, I'ld propose that future kernels SHOULD not only accept leap second upcoming bits from an NTP client s/w, but also hand leap second handling in progress bits back, so as to allow the s/w to mark itself as unsynced via NTP until the effects are over. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-26, Terje Mathisen terje.mathi...@tmsw.no wrote: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. Nope. The function 1 x0; -1, xpi, cos(x) otherwise is continuous and its first derivative is continuous, but its second derivative is not, and its third does not exist at x=0 and pi. It is NOT maximally smooth. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-26, Jochen Bern jochen.b...@linworks.de wrote: On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote: The US will soon be considering a means for dissemination of delta T via NTP Does that read there's *several* teams working on NTPv5 and not communicating with each other right now ... ? The ITU has just met in Geneva and discussed the future of leap seconds. The US is in favor of dropping them, the Brits are in favor of keeping the tradition of leap seconds, [...] Leap seconds are an artefact of a) rotation of Earth (which is ever slowing down because of mechanisms that nothing short of pointing a giant disintegrator ray at the Moon can stop, on top of the uncertainty reflected in the unpredictability of current leap seconds), b) the precision we have achieved in measuring - supposedly immutable - physical time, and c) a desire to have time represented in a way that alludes to the traditional apparent position of the Sun right where I stand (on the surface of the Earth) notion. You can quantize and/or distribute leap seconds in a different way, but you can NOT drop them short of kissing one of these three basics goodbye. No. It arises from the fact that the second is defined according to a physical principle ( the frequency of oscillation of a cesium atom in a certain transition) and the rotation of the earth. It used to be defined by the rotation of the earth (which was the best clock available) 86400 seconds in a mean solar day. But as you say, defined in terms of the oscillations of that transition, the length of the day can vary-- both because of the moon and because of things like earthquakes and global warming. Were we to define the mean solar day as 86400 sec, then it would always be 86400 sec. But theory says that that would make the behaviour of may other systems much more difficult to describe. (If you read through the comments ITU received along with the votes when they put up the poll, you will notice that a great many abolish leap seconds voters proposed schemes that actually do *not* *abolish* the concept of leaps but merely distribute the corrections differently, from infinitesimal leaps to the exceedingly rare leap minute.) Regards, J. Bern ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-26, William Unruh un...@invalid.ca wrote: On 2015-01-26, Jochen Bern jochen.b...@linworks.de wrote: On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote: The US will soon be considering a means for dissemination of delta T via NTP Does that read there's *several* teams working on NTPv5 and not communicating with each other right now ... ? The ITU has just met in Geneva and discussed the future of leap seconds. The US is in favor of dropping them, the Brits are in favor of keeping the tradition of leap seconds, [...] Leap seconds are an artefact of a) rotation of Earth (which is ever slowing down because of mechanisms that nothing short of pointing a giant disintegrator ray at the Moon can stop, on top of the uncertainty reflected in the unpredictability of current leap seconds), b) the precision we have achieved in measuring - supposedly immutable - physical time, and c) a desire to have time represented in a way that alludes to the traditional apparent position of the Sun right where I stand (on the surface of the Earth) notion. You can quantize and/or distribute leap seconds in a different way, but you can NOT drop them short of kissing one of these three basics goodbye. No. It arises from the fact that the second is defined according to a physical principle ( the frequency of oscillation of a cesium atom in a certain transition) and the rotation of the earth. It used to be defined ^not by the rotation of the earth (which was the best clock available) 86400 seconds in a mean solar day. But as you say, defined in terms of the oscillations of that transition, the length of the day can vary-- both because of the moon and because of things like earthquakes and global warming. Were we to define the mean solar day as 86400 sec, then it would always be 86400 sec. But theory says that that would make the behaviour of may other systems much more difficult to describe. (If you read through the comments ITU received along with the votes when they put up the poll, you will notice that a great many abolish leap seconds voters proposed schemes that actually do *not* *abolish* the concept of leaps but merely distribute the corrections differently, from infinitesimal leaps to the exceedingly rare leap minute.) Regards, J. Bern ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 26/01/15 17:11, William Unruh wrote: physical principle ( the frequency of oscillation of a cesium atom in a XX certain transition) and the rotation of the earth. It used to be defined ^not It's a quantum spin flip. There is no physical oscillation. Not that that really changes anything about UTC or TAI. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
David Malone wrote: Terje Mathisen terje.mathi...@tmsw.no writes: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. Doesn't it only have two smooth deritives at the end points or [-w:w]? The usual function is constant 1 with all derivatves zero, and so this is what the derivative should be at the endpoints. They use (1.0 - cos(pi * t / w)) / 2.0, which is 1 at both end point, has first derative zero, but the second deritive is -pi*pi/w/w. The derivatives of sine/cosine are of course +/- cosine/sine, so they stay smooth at all levels. Google uses a half cosine, i.e. something like adjustment = (1-cos(t * pi/adjustment_period))*adjustment_value/2; Since the adjustment_value is +/- a second, the normal form is adjustment = (1-cos(t*pi/adjustment_period))/2; which is zero at t=0 and +1 at t==adjustment_period. (It should be possible to stitch together something that is infinitely smooth, probably using exp(-1/(x*x)), but it would requite a bit more work.) Doesn't seem to be needed? Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Miroslav Lichvar wrote: On Mon, Jan 26, 2015 at 01:03:48PM +0100, Terje Mathisen wrote: One of the good points about Google's smear is the fact that they use a half cosine to distribute the offset, which means that they have a time function which is both continuous and monotonic, as well as having an infinite number of defined derivatives, i.e. it is maximally smooth. They could have chosen a better function though. If its second derivative (wander) started at zero, the NTP clients could adjust their polling interval if necessary before the error gets large and the maximum error between the clients could be minimized. Here is a test showing error between two clients of a server smearing.a large offset. With the cosine function you can see a large spike when smearing started. https://mlichvar.fedorapeople.org/tmp/smear_cos.png https://mlichvar.fedorapeople.org/tmp/smear_sinx.png This seems wrong!?! First of all, you seem to extend the smearing over a million seconds or so? I.e. 10-15 days? How large is the adjustment to be smeared out? The google cosine approach starts with a derivate of zero and ends the same way, I really can't see how that leads to that huge (more than 128 ms!) spike at the start? Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-26, David Woolley david@ex.djwhome.demon.invalid wrote: On 26/01/15 17:11, William Unruh wrote: physical principle ( the frequency of oscillation of a cesium atom in a XX certain transition) and the rotation of the earth. It used to be defined ^not It's a quantum spin flip. There is no physical oscillation. Not that that really changes anything about UTC or TAI. Tell that to the electromagnetic wave that comes out of the atom. The energy of that spin flip corresponds directly to a frequency via Planck's constant. And yes, an actual frequency of oscillation of the EM field. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
I'm expecting that NTPv5 will include things like the timescale used by the timestamp, so as long as the systems agree on how to convert timescales if they are not the same between the client and server (hello, General Timestamp API) it will be OK if an NTPv4 or NTPv5 box talks to an NTPv5 box, as the V5 machines will handle timescale conversions and we can specify in the Standard that v4 boxes speak POSIX, so the machine running the smear must do a conversion. I'll be talking about this a bit in my FOSDEM talk. And while there is much to appreciate about the half-cosine smear, one thing some folks *hate* about it is that time from these machines is wrong on both frequency *and* time, to varying degrees, throughout the day. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern writes: On 01/23/2015 08:03 PM, schmidt.r...@gmail.com wrote: The US will soon be considering a means for dissemination of delta T via = NTP Does that read there's *several* teams working on NTPv5 and not communicating with each other right now ... ? Nobody has talked to me, the NTP Project, or NTF about it. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Sorry for the delay, I'm *still* not back to my usual workplace ... On 01/21/2015 11:39 AM, Mike Cook wrote: I couldn’t find a definition of a monotonous function. Does it exist? As David already suggested, I learnt my math in Germany - and switched to CS before taking a shot at a PhD, which would have required me to tear into actual current research, which would have been written in English. So yes, (streng) monoton should have been translated as (strictly) monotonic, not (strictly) monotonous. (Quick terminology recap: A function takes inputs from one set (domain) and assigns an output/result from another set (codomain) to them. In order to define continuous, both domain and codomain need to be ordered and have a notion of distance or difference (metric).) The function can be non-linear. See below. Yes. In particular, implementing a leap second by decelerating your all minutes have 60 seconds clock results in a conversion function that is monotonic and continuous, but not linear. In the case of having it run at half its normal speed for two seconds, it would qualify as piecewise linear - and not have a defined derivative at the switchover points. For the first version, let us assume that the codomain and its metric have leap seconds incorporated in the same way TAI's codomain integrates leap days. In other words, the metric knows that the distance between 31-Mar-2015 23:59:00 and 01-Apr-2015 00:00:00 is 60 seconds but the one between 30-Jun-2015 23:59:00 and 01-Jul-2015 00:00:00 is 61 seconds. The first result would, of course, be that it's now the metric that fails to be fully defined, as (most of) the future leap seconds are not yet known. This does not prevent the metric from being fully defined. The definition of UTC includes the definition of when a leap second will be inserted without limit to time. 1.1 The magnitude of DUT1 should not exceed 0.8 s. 1.2 The departure of UTC from UT1 should not exceed 0.9 s (see Note 1). 1.3 The deviation of (UTC plus DUT1) should not exceed 0.1 s. There must be a field of maths which includes that notion of « fuzziness ». Yes, but traditional functional analysis isn't it. :-} (Statistics or Limitation Theory come to mind, but I don't have a specific concept on the top of my mind.) The definition of continuous involves looking at arbitrarily small intervals around the points in question. A metric saying that the distance between two points in the future cannot be guaranteed to ever get smaller than the uncertainty means that no such intervals exist, and the definition of continuous falls flat on its face. Variant 2b. It is also conceivable to have a mechanical watch with 61 second divisions, a couple of buttons on the side to push for +/- leap seconds and cams which show/hide the relevant tick marks and speed the second hand from 58 through 0 accordingly at the rate of one SI second I doubt we'll ever see such a *mechanic* watch being made. An *analog* (with hands, and supposedly step motors and electronics driving them, or faking hands with an LCD display or somesuch) or outright digital one, sure. Yes, the conversion to the timescale defined by that watch's second hand's movement would be monotonic, continuous, piecewise linear, invertible, etc.. It still needs additional input (the +/- buttons) to remain true, and entirely separate data (historic list of leap seconds, preferably with checkmarks that the buttons *were* pressed) to accurately compute the time that passed between two readings, though. Again, what you are highlighting is the inability or unwillingness of engineers to create sufficiently robust conversion functions. Well, if you want to put it that way, yes. Though unavailability of leap second info within whatever system they're designing (say, a mechanic wrist watch worn by an average human) is a pretty *solid* reason to claim inability to do so. Regards, J. Bern -- *NEU* - NEC IT-Infrastruktur-Produkte im http://www.linworks-shop.de/: Server--Storage--Virtualisierung--Management SW--Passion for Performance Jochen Bern, Systemingenieur --- LINworks GmbH http://www.LINworks.de/ Postfach 100121, 64201 Darmstadt | Robert-Koch-Str. 9, 64331 Weiterstadt PGP (1024D/4096g) FP = D18B 41B1 16C0 11BA 7F8C DCF7 E1D5 FAF4 444E 1C27 Tel. +49 6151 9067-231, Zentr. -0, Fax -299 - Amtsg. Darmstadt HRB 85202 Unternehmenssitz Weiterstadt, Geschäftsführer Metin Dogan, Oliver Michel ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Anyone wanting to check whether they are being fed spurious leap-second information may like to try my Leap Trace program, available as a Windows GUI and command-line program, and as a Perl script for other OS. http://www.satsignal.eu/software/net.htm#NTPLeapTrace -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Friday, January 23, 2015 at 3:55:02 AM UTC-5, Marco Marongiu wrote: On 21/01/15 15:31, Mike S wrote: On 1/21/2015 2:10 AM, Mike Cook wrote: And one of the reasons why a significant portion of the computing community wants to get rid of leap seconds. A coverup for bad engineering practices. That's right. Instead of recognizing that the world rotates on it's own, they want to change reality so the world rotates around them. Lazy ass programmers, trying to claim that leap seconds cause issues, when it is software which doesn't handle time properly which is the root cause. Two days ago I've been interviewed by the Italian national radio broadcaster about the leap second. It was between 11:30-12:00 Rome time. Closing the interview the host asked me I guess you would be happy if the leap second was suppressed, you'd have quite less problems to handle, wouldn't you?!. And I replied I'd actually be happier if programmers did their job properly, for example not assuming that a minute always lasts 60 seconds, no matter what. Funny that 3 hours later, on the other side of the planet, you have written the same thing... It's a +1 from me, too. I guess it was clear ;-) Ciao -- bronto That was a cute response, but entirely misses the point of the problem with leap seconds. One can program in a leap second only if one knows it is coming. (Though I cannot program the leap second into my vintage 1855 Bond marine chronometer!) What shall you program about the end of June, 2016, or December, 2020? What will be the interval of time between now and then? If you imagine the Earth is a UTC clock, and a transit telescope pointing to the Sun represents the hour hand, we would like to be pointing at the Sun again 24 hrs later. But because the Earth is (now) a poor clock, sometimes it makes it all the way around in a day, and sometimes it does not. In 2015, the Earth is taking per day on average 1.0092 milliseconds more than 24 hours to make a complete rotation. And keep in mind that the estimated accuracy of the value of TAI-UTC 30 days out is three times that daily value, or 3.2 ms. That's the best we can do at present. By eliminating the artifice of leap seconds we no longer need historical tables to compute for example the interval of time between two points moving forward. Astronomers are there already in the use of TT (Terestrial Time) in the computation of ephemerides, which avoids the discontinuity of leap seconds. [Future inhabitants of Mars will have a completely different determination of leap seconds]. The US will soon be considering a means for dissemination of delta T via NTP, which further paves the way for practical elimination of leap seconds. The ITU has just met in Geneva and discussed the future of leap seconds. The US is in favor of dropping them, the Brits are in favor of keeping the tradition of leap seconds, and the Swiss, who found support for both sides, has declared itself neutral (of course!) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/23/2015 2:03 PM, schmidt.r...@gmail.com wrote: What shall you program about the end of June, 2016, or December, 2020? What will be the interval of time between now and then? Depends. What are you doing which requires 1 second accuracy a year or 5 from now? Does it need to happen at a specific time, or a specific interval in the future? Even with all the problems POSIX has with time, cron would still make it happened at a specific time, except possibly during a very short period when a leap second actually occurs. And if you need it at a specific interval in the future, the problem's still not particularly difficult. Many programs need to handle things which are indeterminate in the future. Are you really unable to figure out how to do it, or are you trying to make a problem which doesn't really exist? Note, that if you need 1 second accuracy a year or 5 out, then unless you have an atomic clock you will need some external time input to stay in sync. There's no reason that external time input can't also provide upcoming leap second info well in advance. Either an Internet connection or GPS connection will provide that easily. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh un...@invalid.ca writes: General relativity assures us that time exists and is measured by a metric. Take that metric and define a proper time say at the center of the earth. Now one can ask whether TAI or UTC is a function of that time. As Mike points out, you've subtracted things in a way that doesn't really make sense to make this argument. Warner Losch has a good way of describing this as variable radix. For example, we don't describe the calendar as discontinuous, because months have 28, 29, 30 or 31 days. If you subtract Feb 27th from Mar 3rd, you need to know if it is a leap leap year, rather than say the answer is 7 days by assume all months have 31 days because most months do. My personal way of viewing the topology of the space labels, is that some second labels have multiple possible successor labels, and the leap seconds look like little loops around which UTC may or may not pass. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 21/01/15 15:31, Mike S wrote: On 1/21/2015 2:10 AM, Mike Cook wrote: And one of the reasons why a significant portion of the computing community wants to get rid of leap seconds. A coverup for bad engineering practices. That's right. Instead of recognizing that the world rotates on it's own, they want to change reality so the world rotates around them. Lazy ass programmers, trying to claim that leap seconds cause issues, when it is software which doesn't handle time properly which is the root cause. Two days ago I've been interviewed by the Italian national radio broadcaster about the leap second. It was between 11:30-12:00 Rome time. Closing the interview the host asked me I guess you would be happy if the leap second was suppressed, you'd have quite less problems to handle, wouldn't you?!. And I replied I'd actually be happier if programmers did their job properly, for example not assuming that a minute always lasts 60 seconds, no matter what. Funny that 3 hours later, on the other side of the planet, you have written the same thing... It's a +1 from me, too. I guess it was clear ;-) Ciao -- bronto ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 21/01/15 10:39, Mike Cook wrote: I couldn’t find a definition of a monotonous function. It's an obvious mis-choice of words by someone whose name suggests they aren't native English speaker. It clearly is intended to mean monotonic. See https://en.wikipedia.org/wiki/Monotonic_function for a definition. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh un...@invalid.ca writes: Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. That assumes that UTC can be represented as a real number with the standard topology, which doesn't seem to be what TF.460 says. It describes each second as labelled, which means that you have to stitch together all possible unit intervals for each second with some topology, and then you can ask if the path taken by UTC through this space is continuous. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Mike S schrieb: On 1/21/2015 2:10 AM, Mike Cook wrote: And one of the reasons why a significant portion of the computing community wants to get rid of leap seconds. A coverup for bad engineering practices. That's right. Instead of recognizing that the world rotates on it's own, they want to change reality so the world rotates around them. Lazy ass programmers, trying to claim that leap seconds cause issues, when it is software which doesn't handle time properly which is the root cause. +1 Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/22/2015 1:04 PM, William Unruh wrote: General relativity assures us that time exists and is measured by a metric... still 1 second different in the two scales. And for Jun 30 23:59:59.9 and Jul 1 00:00:00.1 while TAI says that difference is .2 sec, UTC says it is 1.2 sec different. But Jul 1 0:0:0(TAI) is not the same time as Jul 1 0:0:0(UTC), so you're subtracting an apple from an orange, and claiming you got a lemon. It's nonsensical. That for all purposes is a discontinuous function of the time as defined by General relativity. You're in way over your head. And, you're wrong. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Mike S writes: Both TAI and UTC are continuous, and could in a non-standard way, be represented by real numbers (Time, below), where they wouldn't differ. TAI and UTC only differ in how they're labelled, as you say. It's POSIX which isn't monotonic or continuous, it repeats leap seconds. How they handle leap seconds: Time UTC TAI POSIX n+023:59:5800:00:33n+0 n+123:59:5900:00:34n+1 n+223:59:6000:00:35n+2 n+2.9 23:59:60.9 00:00:35.9 n+2.9 n+300:00:0000:00:36n+2 n+3.9 00:00:00.9 00:00:36.9 n+2.9 n+400:00:0100:00:37n+3 The only problem with this approach is that with this approach under POSIX, time is discontiguous - one cannot cleanly map from POSIX to UTC or TAI. This is some of the fun stuff NTFs General Timestamp API gets to deal with. -- Harlan Stenn st...@ntp.org http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-22 11:04, William Unruh wrote: On 2015-01-22, David Malone dwmal...@walton.maths.tcd.ie wrote: William Unruh un...@invalid.ca writes: Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. That assumes that UTC can be represented as a real number with the standard topology, which doesn't seem to be what TF.460 says. It describes each second as labelled, which means that you have to stitch together all possible unit intervals for each second with some topology, and then you can ask if the path taken by UTC through this space is continuous. General relativity assures us that time exists and is measured by a metric. Take that metric and define a proper time say at the center of the earth. Now one can ask whether TAI or UTC is a function of that time. Consider some labeling of the time. Jun 30 23:59:00 and Jul 1 00:01 let us say. Now when we look at TAI, that second one is one second one is 120 seconds ( as measured by that metric) later than the first. For UTC it is 121 seconds later than the first. As one hunts in toward midnight, say Jun 30 23:59:58 vs Jul 1 00:00:02 say, that interval is still 1 second different in the two scales. And for Jun 30 23:59:59.9 and Jul 1 00:00:00.1 while TAI says that difference is .2 sec, UTC says it is 1.2 sec different. That for all purposes is a discontinuous function of the time as defined by General relativity. Now, it is true that UTC does give a name to that second that lies between the two times, but giving it a name does not make the function continous. UTC is a function which is linear and continuous for all times which are not the leap second, but is discontinous at the leap second. The limit of the function as delta t goes to zero of the two scales is not the same. Limit as delta t goes to zero t_relativity (UTC Jun 30 23:59:59.999... -Delta t) is not equal to Limit as delta t goes to zero t_relativity (UTC Jul 1 00:00:00:.0 +Delta t) while it is for TAI. The fact that UTC gives a name ( 23:59:60) to that extra second does not alter the above fact. The fact that UTC publishes a list of when those discontinuities occur is also irrelevant. That one says a function is discontinuous at some value of x and how much it is discontinous, does not alter the fact that it is discontinous. TAI, TT, UTC, UT, UT0, UT1, UT2 are empirical time scales based on measurements not functions, with some scales having fairly simple relations, and UTC stepping by leap seconds. The relative values on these scales are only available accurately when they are published about a month after the time, with estimates available later each day from some labs, based only on those individual labs' standards, which may need corrected later in the month. So none of these simplified arithmetical approaches are anything more than working approximations to the nearest jiffy, and they are not really useful unless you are working in astronomy or physics related fields. POSIX allows you to do useful calculations on civil times based on mean solar seconds, but there are no useful sources for synchronizing or calibrating POSIX time, as all time sources use scales based on SI seconds. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-22, David Malone dwmal...@walton.maths.tcd.ie wrote: William Unruh un...@invalid.ca writes: Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. That assumes that UTC can be represented as a real number with the standard topology, which doesn't seem to be what TF.460 says. It describes each second as labelled, which means that you have to stitch together all possible unit intervals for each second with some topology, and then you can ask if the path taken by UTC through this space is continuous. David. General relativity assures us that time exists and is measured by a metric. Take that metric and define a proper time say at the center of the earth. Now one can ask whether TAI or UTC is a function of that time. Consider some labeling of the time. Jun 30 23:59:00 and Jul 1 00:01 let us say. Now when we look at TAI, that second one is one second one is 120 seconds ( as measured by that metric) later than the first. For UTC it is 121 seconds later than the first. As one hunts in toward midnight, say Jun 30 23:59:58 vs Jul 1 00:00:02 say, that interval is still 1 second different in the two scales. And for Jun 30 23:59:59.9 and Jul 1 00:00:00.1 while TAI says that difference is .2 sec, UTC says it is 1.2 sec different. That for all purposes is a discontinuous function of the time as defined by General relativity. Now, it is true that UTC does give a name to that second that lies between the two times, but giving it a name does not make the function continous. UTC is a function which is linear and continuous for all times which are not the leap second, but is discontinous at the leap second. The limit of the function as delta t goes to zero of the two scales is not the same. Limit as delta t goes to zero t_relativity(UTC Jun 30 23:59:59.... -Delta t) is not equal to Limit as delta t goes to zero t_relativity( UTC Jul 1 00:00:00:.0 +Delta t) while it is for TAI. The fact that UTC gives a name ( 23:59:60) to that extra second does not alter the above fact. The fact that UTC publishes a list of when those discontinuities occur is also irrelevant. That one says a function is discontinuous at some value of x and how much it is discontinous, does not alter the fact that it is discontinous. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/22/2015 5:45 AM, David Malone wrote: That assumes that UTC can be represented as a real number with the standard topology, which doesn't seem to be what TF.460 says. It describes each second as labelled, which means that you have to stitch together all possible unit intervals for each second with some topology, and then you can ask if the path taken by UTC through this space is continuous. Both TAI and UTC are continuous, and could in a non-standard way, be represented by real numbers (Time, below), where they wouldn't differ. TAI and UTC only differ in how they're labelled, as you say. It's POSIX which isn't monotonic or continuous, it repeats leap seconds. How they handle leap seconds: Time UTC TAI POSIX n+023:59:5800:00:33n+0 n+123:59:5900:00:34n+1 n+223:59:6000:00:35n+2 n+2.9 23:59:60.9 00:00:35.9 n+2.9 n+300:00:0000:00:36n+2 n+3.9 00:00:00.9 00:00:36.9 n+2.9 n+400:00:0100:00:37n+3 ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/21/2015 2:10 AM, Mike Cook wrote: And one of the reasons why a significant portion of the computing community wants to get rid of leap seconds. A coverup for bad engineering practices. That's right. Instead of recognizing that the world rotates on it's own, they want to change reality so the world rotates around them. Lazy ass programmers, trying to claim that leap seconds cause issues, when it is software which doesn't handle time properly which is the root cause. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Jochen Bern wrote: On 01/19/2015 08:42 AM, William Unruh wrote: On 2015-01-19, Mike S mi...@flatsurface.com wrote: [...] You two *both* need to get your terminology (and its definitions) right. [...] Wow, IMO this is *very* good summary of the problem, and explanation of the reasons for it. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Programmers universally compute the number of days between two dates by determining the seconds of the two dates (by using a function such as getTimeInMillis() for each date), computing the difference in seconds between the two dates, and dividing the difference by 86,400. I proved this to myself by performing the following experiment with three of Java's date classes, GregorianCalendar, Date, and ZonedDateTime. In pseudocode: For year = 1997 to 2015 Date1 = year, month =1, day =1, hour = minute = second =0 Date2 = year+1, month =1, day =1, hour = minute = second =0 Duration = Date2 - Date1 (in seconds) Print Date1, Date2, Duration Date1 = 1997, month =1, day =1, hour = minute = second =0 Date2 = Date1 + 31_536_000 * 18 + 4 * 86_400 //Add 18 yrs (in secs) + 4 days for leap years Print Date1, Date2 For each of Java's date classes, the Duration was equal to 31,536,000 seconds (= 365 * 86,400) for all years except leap years, when the duration was 31,622,400 (=31,536,000 + 86,400) for 366 days. In the second part, Date1 = Jan 1, 1997 and Date2, which was equal to Date1 plus 18 years of 31,536,000 seconds per year + 4 leap days, equaled Jan 1, 2015. But we know that the duration in seconds of 1997, 1998, 2005, 2008, and 2012 was actually 31,536,001 seconds because each of these years had a leap second added. So, why does it work? Java, at least, is pretty upfront about why it works. Java describes ZonedDateTime (and its various cousins Instant, LocalDateTime, and OffsetDateTime) as implementing a proleptic calendar, where in this case proleptic means what the data and time would have been in times past if they had been using our calendar system. In addition, the Java documentation implies that the new date/time classes (ZonedDateTime, Instant, LocalDateTime, and OffsetDateTime) cannot be used for astronomical calculations. Why? Because they won't be correct. Jan 1, 2015 minus 18 years of 31,536,000 seconds per year - 4 leap days * 86,400 seconds will not produce the time a computer would have indicated on Jan 1, 1997; instead, there will be 5 seconds difference for the 5 leap seconds introduced in that interval. Oracle's justification for their approach is: Given the complexity of accurate timekeeping ..., (the) Java API defines its own time-scale, the Java Time-Scale. The Java Time-Scale divides each calendar day into exactly 86400 subdivisions, known as seconds. These seconds may differ from the SI second. It closely matches the de facto international civil time scale, the definition of which changes from time to time. The Java Time-Scale has slightly different definitions for different segments of the time-line, each based on the consensus international time scale that is used as the basis for civil time. Whenever the internationally-agreed time scale is modified or replaced, a new segment of the Java Time-Scale must be defined for it. Each segment must meet these requirements: .the Java Time-Scale shall closely match the underlying international civil time scale; .the Java Time-Scale shall exactly match the international civil time scale at noon each day; .the Java Time-Scale shall have a precisely-defined relationship to the international civil time scale. (Source: Oracle documentation for the java.time.Instant class.) In other words, the only aspect of time that matters to Java is that the clock, in the present, be perfectly accurate each day at noon. Thus the time Java displays and uses will be accurate, and up to spec, if and only if the user's clock is accurate. BTW, proleptic can be defined as: The representation or assumption of a future (past?) act or development as if presently existing or accomplished. (http://www.merriam-webster.com/dictionary/prolepsis, parentheses added) Proleptic calendar, a calendar that is applied to dates before its introduction. (http://en.wikipedia.org/wiki/Proleptic) Hope this helps. Charles Elliott ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/20/2015 10:58 AM, Martin Burnicki wrote: Wow, IMO this is *very* good summary of the problem, and explanation of the reasons for it. Thanks, but after pondering the topic another night, I found my treatise to still be faulty. :-} Let me try to amend: --- The smaller point first, I suggested that imagining TAI and UTC in the form of an integer counter would help understanding their properties. That was me going overboard, I'm afraid. You *can* try to imagine timescales that way, but in doing so, you'll reduce almost all of them to an instrument keeping count of the physical time ticking by, differing only by the offset from one to the other. How these timescales treat leap seconds *is* a distinguishing feature, and it is directly related to the bare counter's conversion into a date+time representation. As a corrolary, that means that - contradicting what I wrote before - TAI *does* have a notion of days and years by means of having a date+time representation, and since that one doesn't recognize leap seconds, they're *all* 86400, 31536000 (non-leap year), and 31622400 (leap year) seconds long, regardless of leap seconds. --- Back to mathematics. (You might want to run now. ;-) The problem I have with people calling a timescale monotonous or continuous is that those are mathematical terms, and they're defined for *functions*. (Quick terminology recap: A function takes inputs from one set (domain) and assigns an output/result from another set (codomain) to them. In order to define continuous, both domain and codomain need to be ordered and have a notion of distance or difference (metric).) So, what *function* might people be thinking of when they assert those properties to apply (or not) to timescales? The ultimate basis of timekeeping is that physics gives us a concept of time, in particular, a notion of measuring that time as it passes by, by means of a measurable physical unit, the SI second. With that unit and equipment (and barring relativistic effects for the moment), we can complement a set (of events = measurements) with a metric (that tells us how much time passed between any two measurements). What we have got so far is for time what statements like the pencil is half a meter to the right of the ruler are for space: Precise, but local, in need of being put into relation with a global reference frame to be useful. This reference frame needs to be defined, and *that* are agreed-upon timescales like TAI or UTC. And in order to translate our local measurement into such a timescale, we need a *conversion function*. (Which we may later hide from sight by syncing a clock that *knows* the timescale so that we can read the conversion's result from it directly, but that's irrelevant here.) So, what people mean by saying that a *timescale* is monotonous or continuous is that the function converting the readings of a measurement device (or, as the experts call it, clock) into said timescale has these properties. I don't remember much protest against claims that TAI has those properties (but fails to stay well-synced to celestial bodies). Now what about other timescales? Let's take a step back from leap *seconds* and think about leap *days* for a moment. TAI does take *those* into account, the result being that some years have a length of 365 days and others 366 days. Why isn't it an obstacle to labelling TAI as continuous that some years have a 29th of February intervening between the 28th and the 1st of May, and the others don't, apparently skipping an entire day? The answer is that the blame for this behaviour is on the codomain, not the conversion function. The set of date+time values and the metric on it are *defined* in such a way that the distance between 28-Feb-2015 21:30:00 and 01-Mar-2015 22:30:00 is 25 hours, but the distance between 28-Feb-2016 21:30:00 and 01-Mar-2016 22:30:00 is 49 hours. The conversion function now maps 25 hours of clock ticks onto the first timeframe but 49 hours onto the second - and comes out of the ordeal smelling of roses, continuity, and even linearity. Now let's apply that to the UTC timescale, which, unlike TAI, recognizes leap seconds (and sets them apart). I shall define three different versions of what the codomain for the SI-UTC conversion function arguably *could* be, and obtain three different results what properties the matching version of the function consequently has. And *that*, I posit, is why people have so very different views on what the properties of the UTC timescale are. For the first version, let us assume that the codomain and its metric have leap seconds incorporated in the same way TAI's codomain integrates leap days. In other words, the metric knows that the distance between 31-Mar-2015 23:59:00 and 01-Apr-2015 00:00:00 is 60 seconds but the one between 30-Jun-2015 23:59:00 and 01-Jul-2015 00:00:00 is 61 seconds. The first result would, of course, be that it's now the metric that fails to be fully
Re: [ntp:questions] Leap second to be introduced in June
On 1/20/2015 6:14 PM, Jochen Bern wrote: So, what*function* might people be thinking of when they assert those properties to apply (or not) to timescales? TAI = UTC(x) and UTC = TAI(x). And that's part of the problem. There seems to be the thought that if you do that across a leap second, and use a UTC time series (or timestamps, if that makes it more clear), but use a TAI-like scale, there will be discontinuities on the graph, where points (23:59:60) can't be plotted (or the other way, where points make stepwise jumps). But of course, that's wrong, because both scales increase linearly, and there is no discontinuity in either. Both account for every bit of time - linearly, continuously, and monotonically (UTC+x = time+x, if you will). Time+1 in one simply maps to time+1 in the other. The only change is to what that value is called, not the value itself. The real problem is systems (POSIX, particularly), which incorrectly handle time, despite having over 40 years to get it right. They try to please everyone, while pleasing no one. POSIX tracks and does calculations on determinate intervals (seconds since 1/1/1970, and every minute has 60 seconds), and also tries to handle civil time, which has indeterminate intervals (unpredictable 61 second minutes). So it fails by trying to do two mutually exclusive things. It's not a particularly difficult problem to solve (timezone info is regularly updated because of civil changes, historical leap seconds could be, too), but requires thought about whether specific future events should be considered as intervals or absolute time values. (Also, in English, it's monotonic, not monotonous. Monotonous means uninteresting or boring, which this likely is) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Le 21 janv. 2015 à 07:18, Terje Mathisen terje.mathi...@tmsw.no a écrit : Mike S wrote: The real problem is systems (POSIX, particularly), which incorrectly handle time, despite having over 40 years to get it right. They try to please everyone, while pleasing no one. POSIX tracks and does calculations on determinate intervals (seconds since 1/1/1970, and every minute has 60 seconds), and also tries to handle civil time, which has indeterminate intervals (unpredictable 61 second minutes). So it fails by trying to do two mutually exclusive things. Right, POSIX is neither UTC nor TAI: It is mostly a calendar device! POSIX is really measuring day numbers, but using a counter which is scaled by 86400. This means that on any day with a leap second, it is not really using SI seconds as the time base. It's not a particularly difficult problem to solve (timezone info is regularly updated because of civil changes, historical leap seconds could be, too), but requires thought about whether specific future events should be considered as intervals or absolute time values. Since there is no way to know about leap seconds several years into the future, forward POSIX timestamps must always be considered as absolute references. They should never be used for time intervals, even if that is the (by far) most common use today. :-( And one of the reasons why a significant portion of the computing community wants to get rid of leap seconds. A coverup for bad engineering practices. Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
Mike S wrote: The real problem is systems (POSIX, particularly), which incorrectly handle time, despite having over 40 years to get it right. They try to please everyone, while pleasing no one. POSIX tracks and does calculations on determinate intervals (seconds since 1/1/1970, and every minute has 60 seconds), and also tries to handle civil time, which has indeterminate intervals (unpredictable 61 second minutes). So it fails by trying to do two mutually exclusive things. Right, POSIX is neither UTC nor TAI: It is mostly a calendar device! POSIX is really measuring day numbers, but using a counter which is scaled by 86400. This means that on any day with a leap second, it is not really using SI seconds as the time base. It's not a particularly difficult problem to solve (timezone info is regularly updated because of civil changes, historical leap seconds could be, too), but requires thought about whether specific future events should be considered as intervals or absolute time values. Since there is no way to know about leap seconds several years into the future, forward POSIX timestamps must always be considered as absolute references. They should never be used for time intervals, even if that is the (by far) most common use today. :-( Terje -- - Terje.Mathisen at tmsw.no almost all programming can be viewed as an exercise in caching ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second not handled correctly on Windows 8
Harlan Stenn wrote: Martin, If a fix is found for this in time I'll get it in 4.2.8p1. I'm working on this with Juergen, and I hope we get this done. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second not handled correctly on Windows 8
Marco Marongiu wrote: On Linux it worked correctly... That is? Yes. My first tests were more focused on Windows in different versions, and I used just another Linux box with a simple setup (just NTP client, no leap second file) to compare the results against those from windows. I'm going to run more tests with different configurations and will post here if the tests pass or fail. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second not handled correctly on Windows 8
On 19/01/15 09:25, Martin Burnicki wrote: Marco Marongiu wrote: On Linux it worked correctly... That is? Yes. My first tests were more focused on Windows in different versions, and I used just another Linux box with a simple setup (just NTP client, no leap second file) to compare the results against those from windows. I'm going to run more tests with different configurations and will post here if the tests pass or fail. Hm, not sure I got everything but... OK, thanks ;-) ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-19, Mike S mi...@flatsurface.com wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in I AM clearly embarrasing myself, since 86400 is the number of seconds per SAY not year. Slight difference! Of course there are 86401 seconds in a day including a leap second. But UTC only sees 86400. It forgets about one of them. that year, that's the whole point. You may also be interested to learn that a year with the similarly named leap day has 366 days, not the usual 365. Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. I quoted from the document you yourself pointed me at. TAI is continuous. UTC differes from TAI by and interger number of seconds, and that integer changes when a leap second occurs. If x is continous x-n where n changes at some time, is NOT continuous. Nonsense. When there's a leap second, there's a UTC second numbered 23:59:60, ibid. Both UTC and TAI tick forward constantly, with each new second uniquely enumerated. TAI is monotonic and continuous. UTC thus cannot be. Now there's a non-sequitur. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh un...@invalid.ca wrote: On 2015-01-19, Mike S mi...@flatsurface.com wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in I AM clearly embarrasing myself, since 86400 is the number of seconds per SAY not year. Slight difference! Of course there are 86401 seconds in a day including a leap second. But UTC only sees 86400. It forgets about one of them. I am not sure what you mean by sees, but I cant figure a meaning that would be compatible with the fact that UTC clearly identifies 86401 seconds on the day the leap second occurs. Maybe the confusion arises from considering UTC dates as time interval quantities, which they are not, rather than timescale readings. TAI days have 86400s, UTC days may have 86401 seconds ; so it happens that when TAI reads 00h00:00, UTC reads 23:59:60. That is what makes computing time intervals more complicated in UTC than in TAI but neither TAI nor UTC is defined by the number of seconds elapsed since an epoch. -- François Meyer ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 19/01/15 12:15, Mike S wrote: You clearly misunderstood TF.460, because you still have it wrong. There is no discontinuity, the two scales merely count time differently. This is how the time of the next leap second will be enumerated in each: You are relying on an appendix that deals with representation of dates. The main part of the standard is worded in terms of their being missing seconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
[And this is why I wonder why leap seconds are discussed here.] On Mon, Jan 19, 2015 at 7:15 AM, Mike S mi...@flatsurface.com wrote: You clearly misunderstood TF.460 You're using the wrong reference. Try this one from 2007: http://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-27_note_on_UTC-ITU-R.pdf which provides the CCTF rationale for making discontinuous UTC continuous. You can skip to the last page if you like but you shouldn't. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second not handled correctly on Windows 8
On 19/01/15 14:47, Martin Burnicki wrote: Actually I've tested a 4.2.8 client on Linux which only receives the leap second warning from an upstream NTP server. There are other configuration options like presence of a leapsecond file, NTP server mode receiving the announcement from a refclock, etc. I see What I'll test starting (all probably) from February will be how the leap second is handled by recent versions of the Linux kernel and how it is handled by ntpd when kernel discipline is disabled. And then a number of other cases that grows each day :-) Yes, I'll share the results :-) Ciao -- bronto ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Mon, Jan 19, 2015 at 9:56 AM, Mike S mi...@flatsurface.com wrote: You're citing a internal letter, from one BIPM group to another, asking them to bring something before the ITU. It's not normative, it's not informational, it's just correspondence. That doesn't make any sense. When the ITU decides *not* do to something it's equally informative as when they decide to do something. Just to be clear you're saying everyone, including the CCTF (previously cited) and the ITU, that says UTC is discontinuous is wrong? For those wonder that internal letter from CCTF to BIPM notes that The UTC system as defined today is a *stepped* atomic time scale [emphasis mine] which is quoting the ITU and can also be found at http://www.itu.int/net/newsroom/wrc/2012/reports/atomic_time.aspx which discusses why the ITU continues to leave UTC stepped. UTC is a discontinuous time scale composed from segments that are linear transformations of atomic time, the discontinuities being arranged so that UTC approximated UT2 https://en.wikipedia.org/wiki/UT2 until the end of 1971, and UT1 https://en.wikipedia.org/wiki/UT1 thereafter. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/19/2015 8:05 AM, David Woolley wrote: You are relying on an appendix that deals with representation of dates. The main part of the standard is worded in terms of their being missing seconds. How proving that you're unable to provide a quote to back up what is, quite simply, a blatant lie. The word missing appears nowhere in ITU-R TF.460-6. There are no appendices in the standard. Finally, in ITU documents, annexes are normative. 1.8.2.2 annex: An annex to a Recommendation contains material (e.g. technical detail or explanation) which is necessary to its overall completeness and comprehensibility and is therefore considered an integral part of the Recommendation... 1.8.2.3 appendix: An appendix to a Recommendation contains material which is supplementary to and associated with the subject matter of the Recommendation but is not essential to its completeness or comprehensibility... - ITU-T A.1 (10/2008) I've already quoted the relevant part. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/19/2015 10:22 AM, Paul wrote: On Mon, Jan 19, 2015 at 9:56 AM, Mike S mi...@flatsurface.com wrote: You're citing a internal letter, from one BIPM group to another, asking them to bring something before the ITU. It's not normative, it's not informational, it's just correspondence. That doesn't make any sense. When the ITU decides *not* do to something it's equally informative as when they decide to do something. Again, you need to up your understanding of standards terminology. For those wonder that internal letter from CCTF to BIPM notes that The UTC system as defined today is a *stepped* atomic time scale [emphasis mine] which is quoting the ITU and can also be found at http://www.itu.int/net/newsroom/wrc/2012/reports/atomic_time.aspx which discusses why the ITU continues to leave UTC stepped. non-sequitur. They're comparing UTC with TAI. From a TAI perspective, UTC steps backwards. From a UTC perspective, TAI steps forward, going further out of sync with Sol. However, mathematically both are continuous functions. The stepping is a meta-result of the difference in how they enumerate time. UTC is continuous and monotonic. https://en.wikipedia.org/wiki/UT2 FTFY. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/19/2015 9:04 AM, Paul wrote: [And this is why I wonder why leap seconds are discussed here.] On Mon, Jan 19, 2015 at 7:15 AM, Mike S mi...@flatsurface.com wrote: You clearly misunderstood TF.460 You're using the wrong reference. Huh? You plainly don't understand the relationships or how standards work. UTC is defined by the ITU, of which the BIPM is a member, among others. The ITU then makes the BIPM and IERS responsible for the practical realization of UTC. You're citing a internal letter, from one BIPM group to another, asking them to bring something before the ITU. It's not normative, it's not informational, it's just correspondence. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/19/2015 2:42 AM, William Unruh wrote: I quoted from the document you yourself pointed me at. TAI is continuous. UTC differes from TAI by and interger number of seconds, and that integer changes when a leap second occurs. If x is continous x-n where n changes at some time, is NOT continuous. You clearly misunderstood TF.460, because you still have it wrong. There is no discontinuity, the two scales merely count time differently. This is how the time of the next leap second will be enumerated in each: UTC TAI 2015/Jun/30/23:59:58 2015/Jul/1/00:00:33 (nb:35 second delta) 2015/Jun/30/23:59:59 2015/Jul/1/00:00:34 2015/Jun/30/23:59:60 2015/Jul/1/00:00:35 2015/Jul/01/00:00:00 2015/Jul/1/00:00:36 2015/Jul/01/00:00:01 2015/Jul/1/00:00:37 (nb:36 second delta) Now, why don't you think a bit, then tell us where you think the discontinuity is in UTC? Hint: if you think there is a discontinuity, keep thinking. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
William Unruh un...@invalid.ca wrote: On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote: William Unruh un...@invalid.ca wrote: On 2015-01-19, Mike S mi...@flatsurface.com wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in I AM clearly embarrasing myself, since 86400 is the number of seconds per SAY not year. Slight difference! Of course there are 86401 seconds in a day including a leap second. But UTC only sees 86400. It forgets about one of them. I am not sure what you mean by sees, but I cant figure a meaning that would be compatible with the fact that UTC clearly identifies 86401 seconds on the day the leap second occurs. If you ask utc how many seconds there are between now, and exactly three days ago, it ansers 3*86400 even if one of those days had a leap second. Yes of course that leap second occurs on the day, but utc forgets that it did. You are constantly confusing the officially defined UTC time with the implementation in computer operating systems seconds since 1-1-1970 UTC. That implementation neglects the presence of leap seconds. Therefore it has to introduce discontinuity. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On Mon, Jan 19, 2015 at 10:43 AM, Mike S mi...@flatsurface.com wrote: Again, you need to up your understanding of standards terminology. No, if you're going to use jargon you should provide the meanings you're using. Since you clearly have your own version of reality it will help the rest of us. non-sequitur. They're comparing UTC with TAI. From a TAI perspective, UTC steps backwards. From a UTC perspective, TAI steps forward, going further out of sync with Sol. However, mathematically both are continuous functions. I can't believe you actually typed that. I apologize to the list for feeding the troll. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/19/2015 11:58 AM, Paul wrote: On Mon, Jan 19, 2015 at 10:43 AM, Mike S mi...@flatsurface.com mailto:mi...@flatsurface.com wrote: Again, you need to up your understanding of standards terminology. No, if you're going to use jargon you should provide the meanings you're using. Since you clearly have your own version of reality it will help the rest of us. This is well accepted terminology. If you wish to discuss formal standards, you should be familiar with it. https://en.wikipedia.org/wiki/Normative#Standards_documents I can't believe you actually typed that. I'm sorry to have confused you by bringing up math. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/19/2015 11:56 AM, William Unruh wrote: On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote: I am not sure what you mean by sees, but I cant figure a meaning that would be compatible with the fact that UTC clearly identifies 86401 seconds on the day the leap second occurs. If you ask utc how many seconds there are between now, and exactly three days ago, it ansers 3*86400 even if one of those days had a leap second. Yes of course that leap second occurs on the day, but utc forgets that it did. Just, Wow. That's completely wrong. TAI does not as far as I know, have a concept of days. It has seconds. If you want to convert those seconds into things like days, months, etc, that is up to you. No, the canonical form of TAI is ydmhms... So, if we count utc seconds we have 1435733999 1435734000 1435734000 1435734001 ... Those appear to be POSIX times. They're certainly neither UTC nor TAI. You keep saying UTC when you're talking about POSIX, which naively tries to keep both epoch (time since...) and wall (UTC) time, and fails miserably since the two are mutually exclusive. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-19, fm@fr.invalid fm@fr.invalid wrote: William Unruh un...@invalid.ca wrote: On 2015-01-19, Mike S mi...@flatsurface.com wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in I AM clearly embarrasing myself, since 86400 is the number of seconds per SAY not year. Slight difference! Of course there are 86401 seconds in a day including a leap second. But UTC only sees 86400. It forgets about one of them. I am not sure what you mean by sees, but I cant figure a meaning that would be compatible with the fact that UTC clearly identifies 86401 seconds on the day the leap second occurs. If you ask utc how many seconds there are between now, and exactly three days ago, it ansers 3*86400 even if one of those days had a leap second. Yes of course that leap second occurs on the day, but utc forgets that it did. Maybe the confusion arises from considering UTC dates as time interval quantities, which they are not, rather than timescale readings. TAI days have 86400s, UTC days may have 86401 seconds ; so it happens that when TAI reads 00h00:00, UTC reads 23:59:60. TAI does not as far as I know, have a concept of days. It has seconds. If you want to convert those seconds into things like days, months, etc, that is up to you. So, if we count utc seconds we have 1435733999 1435734000 1435734000 1435734001 ... That is what I mean. That is what makes computing time intervals more complicated in UTC than in TAI but neither TAI nor UTC is defined by the number of seconds elapsed since an epoch. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 01/19/2015 08:42 AM, William Unruh wrote: On 2015-01-19, Mike S mi...@flatsurface.com wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 31536000 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 31536001 SI seconds in that year, that's the whole point. You may also be interested to learn that a year with the similarly named leap day has 366 days, not the usual 365. Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. I quoted from the document you yourself pointed me at. TAI is continuous. UTC differes from TAI by and interger number of seconds, and that integer changes when a leap second occurs. If x is continous x-n where n changes at some time, is NOT continuous. Nonsense. When there's a leap second, there's a UTC second numbered 23:59:60, ibid. Both UTC and TAI tick forward constantly, with each new second uniquely enumerated. TAI is monotonic and continuous. UTC thus cannot be. You two *both* need to get your terminology (and its definitions) right. First off, there's an actual timescale UTC (which includes leap seconds, and represents them as the famous 23:59:60) and a timescale that current unixoid (and other) computers use internally that is often referred to as UTC (let me call it time_t from here on). A year with a leap second has 31536001 seconds in UTC (and a great many other timescales/-zones, as long as two consecutive turns of the year have the same UTC offset). time_t claims that the year had 31536000 seconds (if you ask it in the first place). The ultimate reason for this (historic) difference is that while the definition of UTC includes leap seconds and even defines a notation for it, it isn't *self-contained* because of leap seconds being decided on and announced only half a year in advance. Since there was (and is) no universal mechanism to distribute leap second tables to computers, time_t was designed as a self-contained approximation to UTC - at the price of it being neither monotonic nor continuous (relative to physical time, and assuming the traditional step one second back approach) over actual leaps. I do not know whether there is an agreed notion of turn of the year for TAI in the first place (as it deliberately does set itself apart from astronomic events and, thus, years), so I can't really answer how many seconds a TAI year has. Definition and representation of TAI *suggest* a year of 31536000 seconds to me, but note that in this case, the turn of the year is expressedly permitted to wander (all over the calendar, if need be) as leap seconds happen and *are included* in the TAI timescale. Now for the *conversion functions*, where terms like continuous regain their usual mathematical meaning in the first place. Converting either TAI or UTC to time_t is, as mentioned above, neither monotonic nor continuous. Converting from time_t back to TAI or UTC is ambiguous and, thus, not even a function. Both statements above are true because time_t numbers the leap second the exact same as one of the neighboring seconds. Converting between TAI and UTC - imagine them as simple counters for the moment, devoid of representational concepts like hours - is monotonic and continuous, because both timescales include the leap second. Actually it's a *linear* function. Converting between *representations* of TAI and UTC, as in, HH:MM:SS, suffers from the fact that UTC special cases the leap seconds (and we *still* need the table of historic leap seconds to do it). Only *now* we get the apparent(*) result that UTC = TAI - n seconds with an n changing (increasing) in discrete steps over time. Note that the above conversion function is, in fact, incomplete because it fails to produce UTC's special value of 23:59:60 for the leap second itself. A more correct definition would be UTC(TAI) = ( TAI - n ) modulo 24h format for times leading up to a specific leap second, 23:59:60 plus the fractional seconds from TAI during the leap second itself, and ( TAI - (n+1) ) modulo 24h format for times following that leap second. As you can see, the suspected one second jump of the conversion between UTC and TAI has been filled with a unique value that is supposedly sorted between the 23:59:59 and 00:00:00 values of UTC. This repairs the alleged failure of the conversion functions to be monotonic and and continuous. Now let's return to the *incomplete* conversion functions and treat them like they were the whole story - which they actually *are* if only we consider time_t instead of UTC: time_t(TAI) = ( TAI - n ) modulo 24h format until some point TAI=t in time ( TAI - (n+1) ) modulo 24h
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-18 16:04, William Unruh wrote: UTC always has 86400 seconds per year. ITYM POSIX time always has 86.4ks/day - by that definition POSIX keeps legal civil time using mean solar seconds, not SI seconds or leap seconds. Any correspondence between POSIX time, SI seconds, UTC, or TAI, is an artifact of the implementation. As with implementations of local legal civil times with DST adjustments, there can be discontinuities where times are duplicated or missing. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-18, Mike S mi...@flatsurface.com wrote: On 1/14/2015 3:50 AM, Rob wrote: No, it is the inadvertent decision to use UTC as a monotonic clock that causes the trouble. UTC is monotonic. It is POSIX time which has discontinuities when it tries to represent UTC. TAI is monotonic and continuous. UTC thus cannot be. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 2015-01-18, Mike S mi...@flatsurface.com wrote: On 1/13/2015 11:46 PM, William Unruh wrote: That is a translation from seconds to ymdhms. The problem is not there. it is in the UTC seconds. In UTC one second disappears after the leap second, but not before or during. Thus UTC seconds numbering is simply disconinuous (jumps back) . UTC jumps neither forward nor backwards. UTC simply allows minutes of 59, 60 or 61 seconds. There is NO discontinuity. The canonical form of UTC (and TAI) is ymdhms. UTC always has 86400 seconds per year. TF.460 describes very clearly how UTC is enumerated. A positive leap-second begins at 23h 59m 60s and ends at 0h 0m 0s of the first day of the following month. In the case of a negative leap-second, 23h 59m 58s will be followed one second later by 0h 0m 0s of the first day of the following month http://www.itu.int/rec/R-REC-TF.460-6-200202-I/en B International atomic time (TAI) The international reference scale of atomic time (TAI), based on the second (SI), as realized on the rotating geoid, is formed by the BIPM on the basis of clock data supplied by cooperating establishments. It is in the form of a continuous scale, e.g. in days, hours, minutes and seconds from the origin 1 January 1958 (adopted by the CGPM 1971). Note: It is in the form of a continuous scale. C Coordinated universal time (UTC) UTC is the time-scale maintained by the BIPM, with assistance from the IERS, which forms the basis of a coordinated dissemination of standard frequencies and time signals. It corresponds exactly in rate with TAI but differs from it by an integer number of seconds. The UTC scale is adjusted by the insertion or deletion of seconds (positive or negative leapseconds) to ensure approximate agreement with UT1. Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. The issue you're describing is an issue with POSIX time, which doesn't handle leap seconds. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in that year, that's the whole point. You may also be interested to learn that a year with the similarly named leap day has 366 days, not the usual 365. Note UTC differs from TAI by an interger number of seconds, AND that integer changes with the leap second. Ie, it cannot be continuous if TAI is continuous. Nonsense. When there's a leap second, there's a UTC second numbered 23:59:60, ibid. Both UTC and TAI tick forward constantly, with each new second uniquely enumerated. TAI is monotonic and continuous. UTC thus cannot be. Now there's a non-sequitur. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Leap second to be introduced in June
On 1/18/2015 7:15 PM, Mike S wrote: On 1/18/2015 6:04 PM, William Unruh wrote: UTC always has 86400 seconds per year. You clearly don't understand how leap seconds work. You're embarrassing yourself now. When there's a leap second, there are 86401 SI seconds in that year That clearly should read 86401 seconds in the day of the leap second. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
