Leap second functional question - NTP

This is a discussion on Leap second functional question - NTP ; Unruh wrote: > David Woolley writes: >>The current code basically checks the date and only sets the bits if it >>is one of those two days. > > No, it does not. It only sets the bit if it has ...

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast
Results 21 to 40 of 78

Thread: Leap second functional question

  1. Re: Leap second functional question

    Unruh wrote:
    > David Woolley writes:
    >>The current code basically checks the date and only sets the bits if it
    >>is one of those two days.

    >
    > No, it does not. It only sets the bit if it has been told by a majority of
    > its servers that a leap second is coming up. And we had a number of people
    > having trouble in that a leap second seemed to have been announced to them
    > in the middle of Jan this year. Ie, ntp on your system relies on your
    > servers to tell about leap second. It is announce a month before hand and
    > then on the day.


    Which is the "current" code?

    AFAIK the current ntp-stable version 4.2.4p4 still behaves like David
    mentiones, but the current ntp-dev version 4.2.5p113 should behave as Bill
    Unruh mentiones.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  2. Re: Leap second functional question

    Paul,

    Paul.Croome@softwareag.com wrote:
    > See http://www.eecis.udel.edu/~mills/leap.html.
    > That would seem to be the authoritative source.


    That is the authoritative source for the current ntp-dev code, which does
    not necessarily mean that the current -stable or even older -dev versions
    behave as mentioned there.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  3. Re: Leap second functional question

    David Woolley wrote:
    > But you can safely have it set for most of the previous six months and
    > the following six months, whereas the questioner is assuming it must be
    > cleared immediately the leap second has been implemented and not set
    > more than a very short time in advance. (It certainly has to be set
    > hours in advance, because some clients may not have polled within an
    > hour, and each stratum can extend the propagation delay of the setting
    > of the flags.)


    Currently the preferred dates to insert a leap second are end of June or end
    of December. Usually the IERS publishes a new "Bulletin C" a few days after
    one of those dates, indicating whether a leap second would be introduced at
    the next of those dates.

    So if a leap second shall be inserted then it is indeed announced by the
    IERS about 6 months before the leapsecond will occur. However, the bulletin
    explicitely mentions the exact date at which the leap second will be
    inserted.

    E.g. for the last leap seconds which have occurred the GPS satellites have
    started to announce the leap second shortly after the announcement had been
    published by the IERS. However, the data sets of the GPS satellites include
    a GPS week number plus the day number in that week, at the end of which the
    leap second is to be inserted. So even if a leap second for December is
    announce in July, it's clear the leap second must not be inserted at the
    end of September.

    Having an exact date of the leap second available (which is also true for
    the NIST leap second file used by ntpd) is different than just having an
    announcement flag without a specific date.

    In my opinion a protocol which is unable to specify a certain leap second
    date should not start to send a leap second announcement flag before the
    month at the end of which the leap second shall occur. This applies also to
    the leap second indicator (the flag) in the NTP packet.

    Relying on specific dates like end of June and end of December (as done by
    ntpd), or even additionally end of March or end of Septermber is a bad
    practice. The only plausibility check should be for the end of a month.


    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  4. Re: Leap second functional question

    David Woolley writes:

    >Unruh wrote:
    >> David Woolley writes:


    >>> The date error is significant because, once one realizes there are only
    >>> two possible days a year, it becomes unimportant when the flags are set


    >> Well, no, it is still important on those days. It does not occur every year
    >> or every day ( in fact I think we have not had one in about 4 years).


    >But you can safely have it set for most of the previous six months and
    >the following six months, whereas the questioner is assuming it must be
    >cleared immediately the leap second has been implemented and not set
    >more than a very short time in advance. (It certainly has to be set
    >hours in advance, because some clients may not have polled within an
    >hour, and each stratum can extend the propagation delay of the setting
    >of the flags.)
    >>
    >>
    >>
    >>> The current code basically checks the date and only sets the bits if it
    >>> is one of those two days.

    >>
    >> No, it does not. It only sets the bit if it has been told by a majority of
    >> its servers that a leap second is coming up. And we had a number of people


    You are right. I must admit I did not look at the code, but relied on my
    obviously bad memory from a previous thread. Sorry.


    .... (code proving the bit is set only on June 30 or Dec 31 removed)


    >> having trouble in that a leap second seemed to have been announced to them
    >> in the middle of Jan this year. Ie, ntp on your system relies on your
    >> servers to tell about leap second. It is announce a month before hand and
    >> then on the day.


    >That tends to confirm that it has been acceptable to set the flag any
    >time after the preceding candidate time.


  5. Re: Leap second functional question

    Paul.Croome@softwareag.com writes:

    >See http://www.eecis.udel.edu/~mills/leap.html.
    >That would seem to be the authoritative source.


    This of course does not tell you how ntp handles the leap second in case
    the kernel is not able to . Also the document only handles the case ofthe
    insertion of a second, not the deletion of a second. I assume ntp simply
    steps by a second.


    >Paul


  6. Re: Leap second functional question

    Paul.Croome@softwareag.com writes:

    >On Feb 18, 3:41 pm, Unruh wrote:


    >> NTP time is UTC which assumes 86400 seconds in each and every [[year]] day.

    >...


    >My understanding is the opposite: In the UTC time scale, the
    >minute, hour, day, week are of variable duration, depending
    >on the insertion or deletion of leap seconds.


    >In the TAI time scale, the minute, hour, day, week are of
    >constant duration.


    No, in UTC all years are 86400 seconds, even if during that year a second
    was added or subtracted. Ie, utc retains no memory of leap seconds. Thus a
    year with a leap second added has 86400 UTC seconds but 86401 TAI seconds.
    UTC simply erases that leap second from memory. It never existed.


    >Paul



  7. Re: Leap second functional question

    Unruh wrote:
    > Paul.Croome@softwareag.com writes:
    >
    >
    >>On Feb 18, 3:41 pm, Unruh wrote:

    >
    >
    >>>NTP time is UTC which assumes 86400 seconds in each and every [[year]] day.

    >>
    >>...

    >
    >
    >>My understanding is the opposite: In the UTC time scale, the
    >>minute, hour, day, week are of variable duration, depending
    >>on the insertion or deletion of leap seconds.

    >
    >
    >>In the TAI time scale, the minute, hour, day, week are of
    >>constant duration.

    >
    >
    > No, in UTC all years are 86400 seconds, even if during that year a second
    > was added or subtracted. Ie, utc retains no memory of leap seconds. Thus a
    > year with a leap second added has 86400 UTC seconds but 86401 TAI seconds.
    > UTC simply erases that leap second from memory. It never existed.
    >
    >
    >
    >>Paul

    >
    >


    The most interesting thing about leap seconds, as far as I'm concerned,
    is the fact that the last leap second left the timing world in disarray
    for about twenty-four hours. Some added a second, a few subtracted a
    second and some ignored the leap second. It took a long time and, I
    suspect, considerable manual intervention to get all the clocks synched
    up again!



  8. Re: Leap second functional question

    Unruh wrote:

    > No, in UTC all years are 86400 seconds, even if during that year a
    > second was added or subtracted.


    Well, apart from the fact that a day is not a year, there is no denying
    that between 0:00 UTC on one day and the next, there have elapsed 86401
    SI seconds if there has been a leap second.

    > year with a leap second added has 86400 UTC seconds but 86401 TAI
    > seconds.


    Both UTC and TAI count SI-seconds, but you seem to differentiate between
    the two. How you want to express durations "in UTC" or "in TAI" is
    unclear to me and I prefer avoid it altogether.

    N

  9. Re: Leap second functional question

    On Feb 19, 10:52 am, Unruh wrote:
    >
    > No, in UTC all years are 86400 seconds, even if during that year a second
    > was added or subtracted. Ie, utc retains no memory of leap seconds.


    Aren't you confusing UTC and GMT? Or maybe I'm the one confusing
    both...

    Thanks.

  10. Re: Leap second functional question

    Nero Imhard writes:

    >Unruh wrote:


    >> No, in UTC all years are 86400 seconds, even if during that year a
    >> second was added or subtracted.


    >Well, apart from the fact that a day is not a year, there is no denying
    >that between 0:00 UTC on one day and the next, there have elapsed 86401
    >SI seconds if there has been a leap second.


    Yes, but UTC ignores that and assumes that only 86400 seconds have occured,
    even though 86401 actually occured. It simply ignores that extra second.
    That is the beauty of utc.



    >> year with a leap second added has 86400 UTC seconds but 86401 TAI
    >> seconds.


    >Both UTC and TAI count SI-seconds, but you seem to differentiate between
    >the two. How you want to express durations "in UTC" or "in TAI" is
    >unclear to me and I prefer avoid it altogether.


    Yes, I differentiate because UTC does. UTC assumes despite the facts that
    only 86400 seconds have occured. You may have lived through and experienced
    that extra second ( eg having to wait and extra second before you yelled
    Happy New Year) but UTC erases it from history. It says that that Dec only had
    31*86400 seconds, no matter what your experience said.

    Thus the number of seconds from Dec 1 0:0:0 to Jan 1 0:0:0 is 31*86400 under
    UTC always. If you are an astromomer this is of course a disaster since
    there were actually one more second there, but UTC does not care.
    Astronomers do not use UTC.



    >N


  11. Re: Leap second functional question

    Unruh wrote:

    > there were actually one more second there, but UTC does not care.
    > Astronomers do not use UTC.


    Astronomers use UT1 or higher. These DO have variable length seconds,
    which I think was the original cause of confusion; I think they mixed up
    UT1 with UTC.

    UT1 is more closely based on earth rotation time. Leap seconds are
    introduced when the discrepancy between UTC and UT1 is getting too high
    (somewhere between half and one second). Various time signals include
    this difference to a tenth of a second, or maybe better.

    The UT1 second count is always close to the UTC second count, and so UTC
    second counts are more useful for astronomers than TAI ones, except if
    you are using an epoch close to a leap second and measuring times close
    on the other side.

    I doubt that a year actually exists in TAI. When people talk about
    using TAI in computers, they are talking about the internal seconds
    count, not any external representation of it.

    >
    >
    >
    >> N


  12. Re: Leap second functional question

    Evandro Menezes wrote:

    > Aren't you confusing UTC and GMT? Or maybe I'm the one confusing
    > both...


    Nearly everyone confuses UTC and GMT. GMT is an obsolete name for UT1,
    or something close, but the BBC still uses it to, incorrectly, mean UTC.

  13. Re: Leap second functional question

    David Woolley writes:

    >Unruh wrote:


    >> there were actually one more second there, but UTC does not care.
    >> Astronomers do not use UTC.


    >Astronomers use UT1 or higher. These DO have variable length seconds,
    >which I think was the original cause of confusion; I think they mixed up
    >UT1 with UTC.


    Well, no. Astronomers use TAI since long baseline interferometery relies on
    accurate time synchronization. The deep space network uses TAI since the
    speed of light must not change from year to year.

    >UT1 is more closely based on earth rotation time. Leap seconds are
    >introduced when the discrepancy between UTC and UT1 is getting too high
    >(somewhere between half and one second). Various time signals include
    >this difference to a tenth of a second, or maybe better.


    Yes, UTC is an attempt to base the time on the earth's rotation. But the
    price is that the time differences are not accurate. The number of seconds
    from time A to B under UTC is not proportional to the number of oscillation
    of a cesium atom. It varies.


    >The UT1 second count is always close to the UTC second count, and so UTC
    > second counts are more useful for astronomers than TAI ones, except if
    >you are using an epoch close to a leap second and measuring times close
    >on the other side.


    >I doubt that a year actually exists in TAI. When people talk about
    >using TAI in computers, they are talking about the internal seconds
    >count, not any external representation of it.


    Yes. But then your computer's itnernal time IS the number of seconds since
    epoch. (1970 for Unix) But it is not really the number of seconds. It is
    the number of UTC seconds. which differs from the actual number of seconds.

    Software converts those number of seconds since epoch into a date. They
    could easily do that with TAI as with UTC except that they would need a
    table of leap seconds. But then they need a table of time zones anyway, so
    what's another table.



    >>
    >>
    >>
    >>> N


  14. Re: Leap second functional question

    On 2008-02-20, Unruh wrote:
    > Well, no. Astronomers use TAI since long baseline interferometery relies on
    > accurate time synchronization. The deep space network uses TAI since the
    > speed of light must not change from year to year.


    I suppose it is rather unfair of me to point out that I'm a
    professional astronomer, and can assure you lots of astronomers use
    UTC.


  15. Re: Leap second functional question

    Unruh schreef:

    > Yes, I differentiate because UTC does. UTC assumes despite the facts
    > that only 86400 seconds have occured.


    That is simply not true. I re-read earlier posts and I think that I have
    found where confusion crept in. You are probably mistaking the
    representation for the actual time scale. Earlier, you wrote:

    > NTP time is UTC which assumes 86400 seconds in each and every year.


    It seems that you are actually referring to NTP time, which is UTC
    represented in a POSIX-like manner, i.e. as a continuous count of
    seconds since some epoch. It is this particular (flawed) representation
    that ignores the leap seconds; not UTC itself.

    N

  16. Re: Leap second functional question

    Unruh wrote:
    > David Woolley writes:
    >
    >> Unruh wrote:

    >
    >>> there were actually one more second there, but UTC does not care.
    >>> Astronomers do not use UTC.

    >
    >> Astronomers use UT1 or higher. These DO have variable length seconds,
    >> which I think was the original cause of confusion; I think they mixed up
    >> UT1 with UTC.

    >
    > Well, no. Astronomers use TAI since long baseline interferometery relies on
    > accurate time synchronization. The deep space network uses TAI since the
    > speed of light must not change from year to year.


    Astronomers need both earth rotation time and TAI, although I would
    argue that long baseline interferometry only has a weak case for TAI
    over UTC as the distinction only causes a problem for a fraction of a
    second every few years.

    Optical astronomers need some form of earth rotation time if they are
    working with right ascensions to better than about 1 part in 5,000.
    Planetary astronomers may also need TAI, because orbital dynamics will
    be closer to that than any other available standard. The fact that UT1
    to UTC differences can be measured, means that they can need earth
    rotation time more accurately than UTC.

    Long baseline interferometry also needs both, although it only needs TAI
    over the time it takes light to cross the array, so using UTC only
    causes problem at the edges of leap seconds.
    >
    >
    > Yes, UTC is an attempt to base the time on the earth's rotation. But the
    > price is that the time differences are not accurate. The number of seconds
    > from time A to B under UTC is not proportional to the number of oscillation
    > of a cesium atom. It varies.


    It's a compromise, in which the discrepancies are infrequent and only an
    exact number of seconds. It's a good compromise for commercial and
    legal use, where one almost certainly really wants earth rotation time.
    >


    > Software converts those number of seconds since epoch into a date. They
    > could easily do that with TAI as with UTC except that they would need a
    > table of leap seconds. But then they need a table of time zones anyway, so
    > what's another table.


    Please supply me with the leap second table for the next 100 years. I
    know that legislatures mess around with timezone tables, but they at
    least tend to do so in units of at least half an hour and the general
    public are used to such effects. (For commercial and legal purposes,
    even UTC is often too abstract to be useful for time periods of more
    than a few days.) Generally the POSIX v "True" time debate is one that
    recurs but is never resolved.

  17. Re: Leap second functional question

    Nero Imhard wrote:
    > Both UTC and TAI count SI-seconds, but you seem to differentiate between
    > the two. How you want to express durations "in UTC" or "in TAI" is
    > unclear to me and I prefer avoid it altogether.


    IMHO both UTC and TAI have their advantages, depending on the application.

    While UTC is a better choice to use time stamps / calendar dates across leap
    seconds (i.e Jan 1 00:00:00 = Dec 1 00:00:00 + (31*86400) TAI is preferred
    if correct time _intervals_ are required, even across a leap second.

    Martin
    --
    Martin Burnicki

    Meinberg Funkuhren
    Bad Pyrmont
    Germany

  18. Re: Leap second functional question

    David Woolley wrote:
    > Unruh wrote:
    >
    >> David Woolley writes:
    >>
    >>> Unruh wrote:

    >>
    >>
    >>>> there were actually one more second there, but UTC does not care.
    >>>> Astronomers do not use UTC.
    >>>

    >>
    >>> Astronomers use UT1 or higher. These DO have variable length
    >>> seconds, which I think was the original cause of confusion; I think
    >>> they mixed up UT1 with UTC.

    >>
    >>
    >> Well, no. Astronomers use TAI since long baseline interferometery
    >> relies on
    >> accurate time synchronization. The deep space network uses TAI since the
    >> speed of light must not change from year to year.

    >
    >
    > Astronomers need both earth rotation time and TAI, although I would
    > argue that long baseline interferometry only has a weak case for TAI
    > over UTC as the distinction only causes a problem for a fraction of a
    > second every few years.
    >
    > Optical astronomers need some form of earth rotation time if they are
    > working with right ascensions to better than about 1 part in 5,000.
    > Planetary astronomers may also need TAI, because orbital dynamics will
    > be closer to that than any other available standard. The fact that UT1
    > to UTC differences can be measured, means that they can need earth
    > rotation time more accurately than UTC.
    >
    > Long baseline interferometry also needs both, although it only needs TAI
    > over the time it takes light to cross the array, so using UTC only
    > causes problem at the edges of leap seconds.
    >
    >>
    >>
    >> Yes, UTC is an attempt to base the time on the earth's rotation. But the
    >> price is that the time differences are not accurate. The number of
    >> seconds
    >> from time A to B under UTC is not proportional to the number of
    >> oscillation
    >> of a cesium atom. It varies.

    >
    >
    > It's a compromise, in which the discrepancies are infrequent and only an
    > exact number of seconds. It's a good compromise for commercial and
    > legal use, where one almost certainly really wants earth rotation time.
    >
    >>

    >
    >> Software converts those number of seconds since epoch into a date. They


    >
    > Please supply me with the leap second table for the next 100 years. I
    > know that legislatures mess around with timezone tables, but they at
    > least tend to do so in units of at least half an hour and the general
    > public are used to such effects. (For commercial and legal purposes,
    > even UTC is often too abstract to be useful for time periods of more
    > than a few days.) Generally the POSIX v "True" time debate is one that
    > recurs but is never resolved.


    You are asking for the impossible! Leap seconds keep time in synch with
    the earth's rotation. The rate of rotation is subject to small
    variations. This is why leap seconds occur at irregular intervals and
    why it is possible to have a negative leap second, although I don't
    recall that we ever had one.


  19. Re: Leap second functional question

    Greg Hennessy writes:

    >On 2008-02-20, Unruh wrote:
    >> Well, no. Astronomers use TAI since long baseline interferometery relies on
    >> accurate time synchronization. The deep space network uses TAI since the
    >> speed of light must not change from year to year.


    >I suppose it is rather unfair of me to point out that I'm a
    >professional astronomer, and can assure you lots of astronomers use
    >UTC.


    No very fair. Professional information should trump amatuer every time.
    However, I suspect strongly that when you actually do your calculations you
    use TAI. Ie, determining the orbits of sattelites or planets and throwing
    away random seconds of time is not a good thing.
    So, I guess the pertinant question is "when do you use UTC"? For your daily
    life I am sure. For astronomical calculations, I really hope not unless a
    second every few years does not matter.


  20. Re: Leap second functional question

    David Woolley writes:

    >Unruh wrote:
    >> David Woolley writes:
    >>
    >>> Unruh wrote:

    >>
    >>>> there were actually one more second there, but UTC does not care.
    >>>> Astronomers do not use UTC.

    >>
    >>> Astronomers use UT1 or higher. These DO have variable length seconds,
    >>> which I think was the original cause of confusion; I think they mixed up
    >>> UT1 with UTC.

    >>
    >> Well, no. Astronomers use TAI since long baseline interferometery relies on
    >> accurate time synchronization. The deep space network uses TAI since the
    >> speed of light must not change from year to year.


    >Astronomers need both earth rotation time and TAI, although I would
    >argue that long baseline interferometry only has a weak case for TAI
    >over UTC as the distinction only causes a problem for a fraction of a
    >second every few years.


    Yes, of course -- because UTC and TAi time differences only differ at those
    times. And at those times they use TAI. So they use TAI, since that is what
    they use at the only times when the difference is important.


    >Optical astronomers need some form of earth rotation time if they are
    >working with right ascensions to better than about 1 part in 5,000.
    >Planetary astronomers may also need TAI, because orbital dynamics will
    >be closer to that than any other available standard. The fact that UT1


    No orbital dynamics obeys Newton's ( or Einstein's) law of gravitation only
    in TAI not in UTC ot UT1. While earth rotation was adequate for many many
    centuries as a clock, it is not any longer. IF you are doing something
    where you do not give a damn about how many seconds there are in a year, of
    course, use UTC. If what you want is to know when Gamma draconis is
    overhead in London, please use UT1, not UTC, since that IS determined by
    the earth's rotation. If you want to know when the double Binary Plusar's B
    plusar is next going to blink, you had better use TAI, not UT1 or UTC.


    >to UTC differences can be measured, means that they can need earth
    >rotation time more accurately than UTC.


    Yes, they can. And if I want to know when the next tube from Golder's Green
    goes, none of those time standards is of any use whatsoever.


    >Long baseline interferometry also needs both, although it only needs TAI
    >over the time it takes light to cross the array, so using UTC only
    >causes problem at the edges of leap seconds.
    >>
    >>
    >> Yes, UTC is an attempt to base the time on the earth's rotation. But the
    >> price is that the time differences are not accurate. The number of seconds
    >> from time A to B under UTC is not proportional to the number of oscillation
    >> of a cesium atom. It varies.


    >It's a compromise, in which the discrepancies are infrequent and only an
    >exact number of seconds. It's a good compromise for commercial and
    >legal use, where one almost certainly really wants earth rotation time.


    Agreed. for commercial and legal use it is fine. For accurate timing work
    it is terrible. It is not good for earth rotation (UT1 is better) and it is
    not good for accurate timing (TAI is better).


    >>


    >> Software converts those number of seconds since epoch into a date. They
    >> could easily do that with TAI as with UTC except that they would need a
    >> table of leap seconds. But then they need a table of time zones anyway, so
    >> what's another table.


    >Please supply me with the leap second table for the next 100 years. I
    >know that legislatures mess around with timezone tables, but they at
    >least tend to do so in units of at least half an hour and the general
    >public are used to such effects. (For commercial and legal purposes,
    >even UTC is often too abstract to be useful for time periods of more
    >than a few days.) Generally the POSIX v "True" time debate is one that
    >recurs but is never resolved.


    Of course I cannot. Leap seconds are to take into account the random
    variations in the earth's rotation to one part in about 10^8.

+ Reply to Thread
Page 2 of 4 FirstFirst 1 2 3 4 LastLast