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 a écrit : > > Terje Mathisen writes: >> cmad...@cmadams.net (Chris Adams) wrote: >>> Also,

Re: [ntp:questions] Leap second to be introduced in June

strange response! > Le 11 janv. 2015 à 21:18, Paul 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?

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

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 l

Re: [ntp:questions] Leap second to be introduced in June

David Malone wrote: Terje Mathisen 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

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.fedor

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 o

Re: [ntp:questions] Leap second to be introduced in June

Terje Mathisen 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

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

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

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

Re: [ntp:questions] Leap second to be introduced in June

On 2015-01-26, David Woolley 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 >>

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 deri

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 s

Re: [ntp:questions] Leap second to be introduced in June

David Malone wrote: Terje Mathisen 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 derivative

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 havi

Re: [ntp:questions] Leap second to be introduced in June

On 2015-01-26, William Unruh wrote: > On 2015-01-26, Jochen Bern 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

Re: [ntp:questions] Leap second to be introduced in June

On 2015-01-26, Jochen Bern 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 I

Re: [ntp:questions] Leap second to be introduced in June

On 2015-01-26, 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 derivat

Re: [ntp:questions] Leap second to be introduced in June

Terje Mathisen 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 ma

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

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 f

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

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

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 w

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:

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 sp

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 > >> enginee

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_funct

Re: [ntp:questions] Leap second to be introduced in June

William Unruh 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 th

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

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 wrote: William Unruh 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 repre

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 seco

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.00

Re: [ntp:questions] Leap second to be introduced in June

On 2015-01-22, David Malone wrote: > William Unruh 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 >

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

Re: [ntp:questions] Leap second to be introduced in June

William Unruh 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 wh

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 ch

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

Re: [ntp:questions] Leap second to be introduced in June

> > 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) s

Re: [ntp:questions] Leap second to be introduced in June

> Le 21 janv. 2015 à 07:18, Terje Mathisen 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 >> calculation

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 h

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, an

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 f

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

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 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 B

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 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, the

Re: [ntp:questions] Leap second to be introduced in June

William Unruh wrote: > On 2015-01-19, fm@fr.invalid wrote: >> William Unruh wrote: >>> On 2015-01-19, 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

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 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 second

Re: [ntp:questions] Leap second to be introduced in June

On 2015-01-19, fm@fr.invalid wrote: > William Unruh wrote: >> On 2015-01-19, 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'

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 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

Re: [ntp:questions] Leap second to be introduced in June

On Mon, Jan 19, 2015 at 10:43 AM, Mike S 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

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 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

Re: [ntp:questions] Leap second to be introduced in June

On Mon, Jan 19, 2015 at 9:56 AM, Mike S 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

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 wrote: You clearly misunderstood TF.460 You're using the wrong reference. Huh? You plainly don't understand the relationships or how standards work. U

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.

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 wrote: > You clearly misunderstood TF.460 > You're using the wrong reference. Try this one from 2007: which provid

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

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.

Re: [ntp:questions] Leap second to be introduced in June

William Unruh wrote: > On 2015-01-19, 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

Re: [ntp:questions] Leap second to be introduced in June

On 2015-01-19, 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 I AM clearly embarrasing my

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

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

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 l

Re: [ntp:questions] Leap second to be introduced in June

On 2015-01-18, Mike S 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. UT

Re: [ntp:questions] Leap second to be introduced in June

On 2015-01-18, Mike S 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 sim

Re: [ntp:questions] Leap second to be introduced in June

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. ___ questions mailing list ques

Re: [ntp:questions] Leap second to be introduced in June

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

Re: [ntp:questions] Leap second to be introduced in June

Jochen Bern writes: > ... > > We all know that the current NTP protocol leans toward UTC, and > doesn't address any leap seconds except the one that might be at hand > right now. In recent posts to this list, I've read about plans for an > NTPng that allows for different timescales, but still sug

Re: [ntp:questions] Leap second to be introduced in June

On 01/16/2015 05:41 AM, Chris Adams wrote: > I think one problem with OS clocks in TAI is that counting it correctly > requires active/on-going maintenance at unknownable intervals for all > systems that use any form of timestamps (including for example anything > that uses network file systems).

Re: [ntp:questions] Leap second to be introduced in June

On 2015-01-16, Chris Adams wrote: > Once upon a time, Phil W Lee said: >>For the tiny number of programs which really need UTC (not TAI), it >>would just be a different number, but the only thing I know of which >>really needs UTC rather than TAI would be programs to assist with >>astronomy or a

Re: [ntp:questions] Leap second to be introduced in June

Terje Mathisen wrote: OK, so exactly as encoded in the "right" zone info, there is no leap second until the table is updated/patched. And yet there is no expiration date in the TZDB's leap second file (which is also used for the "right" time zones), so you don't know if there is no upcoming l

Re: [ntp:questions] Leap second to be introduced in June

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 > > 201

Re: [ntp:questions] Leap second to be introduced in June

cmad...@cmadams.net (Chris Adams) wrote: Once upon a time, Phil W Lee said: For the tiny number of programs which really need UTC (not TAI), it would just be a different number, but the only thing I know of which really needs UTC rather than TAI would be programs to assist with astronomy or as

Re: [ntp:questions] Leap second to be introduced in June

David Woolley wrote: On 15/01/15 07:56, Terje Mathisen wrote: Did we have a leap second last June? Or did you intend to check for 2015? Oops. I did get it right in the dry run, but not in the run I actually used: david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2015 86400

Re: [ntp:questions] Leap second to be introduced in June

Once upon a time, Phil W Lee said: >For the tiny number of programs which really need UTC (not TAI), it >would just be a different number, but the only thing I know of which >really needs UTC rather than TAI would be programs to assist with >astronomy or astral navigation. I think one problem wi

Re: [ntp:questions] Leap second to be introduced in June

On 15/01/15 07:56, Terje Mathisen wrote: Did we have a leap second last June? Or did you intend to check for 2015? Oops. I did get it right in the dry run, but not in the run I actually used: david@dhcppc4:~$ TZ=/usr/share/zoneinfo/right/UTC date -d '30 June 2015 86400 seconds' Wed Jul 1

Re: [ntp:questions] Leap second to be introduced in June

David Woolley wrote: On 14/01/15 16:37, Terje Mathisen wrote: The calls I'm thinking of are those you make to convert an OS-supplied time_t (file) system timestamp to YMDHMS etc. Those calls have no need to be in the kernel, and they are not in Unix/Linux systems. The standard GetSystemTime*

Re: [ntp:questions] Leap second to be introduced in June

On 14/01/15 16:37, Terje Mathisen wrote: The calls I'm thinking of are those you make to convert an OS-supplied time_t (file) system timestamp to YMDHMS etc. Those calls have no need to be in the kernel, and they are not in Unix/Linux systems. I.e. even Windows (which uses a seconds-based ti

Re: [ntp:questions] Leap second to be introduced in June

On 2015-01-14, Erwan David wrote: > Harlan Stenn disait le 01/13/15 que : > >> Martin Burnicki writes: >>> Terje Mathisen wrote: I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, might be one of the better

Re: [ntp:questions] Leap second to be introduced in June

Paul wrote: On Wed, Jan 14, 2015 at 5:00 AM, Terje Mathisen wrote: By _far_ the largest majority of all system time calls are asking for the _current_ time, right? Are there (common) systems that have kernel calls for other than the current time? The calls I'm thinking of are those you

Re: [ntp:questions] Leap second to be introduced in June

Jochen Bern wrote: On 01/13/2015 09:33 AM, Terje Mathisen wrote: I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, [...] For distributed logging you have to use the same method for every single node, but that is the ca

Re: [ntp:questions] Leap second to be introduced in June

Jochen Bern wrote: On 01/13/2015 09:33 AM, Terje Mathisen wrote: I hate to admit it, but I'm starting to believe Google's approach, where they smear the leap second over something like a day, [...] For distributed logging you have to use the same method for every single node, but that is the ca

Re: [ntp:questions] Leap second to be introduced in June

On Wed, Jan 14, 2015 at 5:00 AM, Terje Mathisen wrote: > By _far_ the largest majority of all system time calls are asking for the > _current_ time, right? Are there (common) systems that have kernel calls for other than the current time? ___ questio

Re: [ntp:questions] Leap second to be introduced in June

On 01/13/2015 09:33 AM, Terje Mathisen wrote: > I hate to admit it, but I'm starting to believe Google's approach, where > they smear the leap second over something like a day, [...] > > For distributed logging you have to use the same method for every single > node, but that is the case today as

Re: [ntp:questions] Leap second to be introduced in June

William Unruh wrote: Now you could have the computer run in TAI and then do the translation in userland software. But of course since most things expect utc seconds, every call to the clock would require you figuring out what the offset from utc to tai is, and subtract that number, making time sy

Re: [ntp:questions] Leap second to be introduced in June

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) . > And it is that which is th

Re: [ntp:questions] Leap second to be introduced in June

Erwan David writes: > Harlan Stenn disait le 01/13/15 que : > > > Martin Burnicki writes: > >> Terje Mathisen wrote: > >>> I hate to admit it, but I'm starting to believe Google's approach, > >>> where they smear the leap second over something like a day, might be > >>> one of the better workarou

Re: [ntp:questions] Leap second to be introduced in June

Harlan Stenn disait le 01/13/15 que : > Martin Burnicki writes: >> Terje Mathisen wrote: >>> I hate to admit it, but I'm starting to believe Google's approach, >>> where they smear the leap second over something like a day, might be >>> one of the better workarounds. > > This won't work for a bun

Re: [ntp:questions] Leap second to be introduced in June

On 2015-01-14, Phil W Lee wrote: > brian utterback considered Mon, 12 Jan > 2015 04:29:21 GMT the perfect time to write: > >> >>On 1/11/2015 4:56 PM, Rob wrote: >>> Michael Moroney wrote: If I have a system synchronized with a public NTP source, which is synchronized with an atomic cl

Re: [ntp:questions] Leap second to be introduced in June

Harlan Stenn writes: > David Taylor writes: > > On 13/01/2015 08:58, Hal Murray wrote: > > [] > > > How often do people working with log files from 2 systems care about > > > fractions of a second? > > I have spoken with enterprise users who have to correlate logging > timestamps between 50-200 (o

Re: [ntp:questions] Leap second to be introduced in June

Martin Burnicki writes: > Terje Mathisen wrote: >> I hate to admit it, but I'm starting to believe Google's approach, >> where they smear the leap second over something like a day, might be >> one of the better workarounds. This won't work for a bunch of folks. Other folks *hate* this approach be

Re: [ntp:questions] Leap second to be introduced in June

David Taylor writes: > On 13/01/2015 08:58, Hal Murray wrote: > [] > > How often do people working with log files from 2 systems care about > > fractions of a second? I have spoken with enterprise users who have to correlate logging timestamps between 50-200 (or more) systems in cloud deployments

Re: [ntp:questions] Leap second to be introduced in June

Harlan Stenn wrote: Marco Marongiu writes: On 12/01/15 06:10, William Unruh wrote: I also admit I do not know how windows impliments leap seconds. I don't have a reference, but I remember that at the time of the latest leap second I read that Windows will half the clock speed at 23:59:59 so t

Re: [ntp:questions] Leap second to be introduced in June

Terje Mathisen wrote: Brian Utterback wrote: On 1/12/2015 6:29 AM, Mike Cook wrote: Not true. That would violate POSIX. There is no "properly implements", or "right thing". Perhaps you're unaware that POSIX isn't the One True Operating System specification. "Properly implements" means it foll

Re: [ntp:questions] Leap second to be introduced in June

Marco Marongiu wrote: On 12/01/15 11:48, Martin Burnicki wrote: Fortunately Dave Hart had some time to have a closer look at this, and fix it for 4.2.6, so unless something has been broken again in the mean time it should be fixed in 4.2.6 and later, and should work correctly. Let me understan

Re: [ntp:questions] Leap second to be introduced in June

On 13/01/2015 08:58, Hal Murray wrote: [] How often do people working with log files from 2 systems care about fractions of a second? I am comparing log files with a user in another country, where we are looking at errors in satellite data. As there can be many messages per second, using NTP

Re: [ntp:questions] Leap second to be introduced in June

Hal Murray writes: > [Context is google-smear.] > > > For distributed logging you have to use the same method for every single > > node, but that is the case today as well. :-( > > > I.e. with one domain smearing and another stepping, the times between them > > will be skewed over the entire sme

Re: [ntp:questions] Leap second to be introduced in June

[Context is google-smear.] > For distributed logging you have to use the same method for every single > node, but that is the case today as well. :-( > I.e. with one domain smearing and another stepping, the times between them > will be skewed over the entire smearing period. How often do peop

Re: [ntp:questions] Leap second to be introduced in June

Brian Utterback wrote: On 1/12/2015 6:29 AM, Mike Cook wrote: Not true. That would violate POSIX. There is no "properly implements", or "right thing". Perhaps you're unaware that POSIX isn't the One True Operating System specification. "Properly implements" means it follows the well defined, 4

  1   2   >