ntpd sets clock to the year 1939 - NTP

This is a discussion on ntpd sets clock to the year 1939 - NTP ; Hello, I am working with embedded Linux systems (Gumstix) which appear to lack a persistent clock so whenever they are rebooted, their system clocks go back to January 1, 1970. I am hoping to use ntpd to set the clock ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: ntpd sets clock to the year 1939

  1. ntpd sets clock to the year 1939

    Hello,

    I am working with embedded Linux systems (Gumstix) which appear to
    lack
    a persistent clock so whenever they are rebooted, their system clocks
    go
    back to January 1, 1970. I am hoping to use ntpd to set the clock on
    these
    systems but I am getting an unexpected result.

    When I run ntpd on the Gumstix, without the -g option it complains
    that the
    time difference between the local clock and the server is too great.
    OK, I expected that. However, when I run it again with -g, ntpd
    happily
    makes a big adjustment in the local time ... changing it from 1970 to
    1939 for some reason. I tried a couple of different servers but got
    the same
    result.

    Here's the content of /etc/ntp.conf (sans most of the comments):

    restrict default nomodify notrap noquery
    restrict 127.0.0.1
    # server 0.pool.ntp.org
    # server 1.pool.ntp.org
    # server 2.pool.ntp.org
    server time.cachenetworks.com
    driftfile /var/lib/ntp/drift

    Here's the output from /var/log/messages.
    The first output is without -g option and second one is with -g.
    ....
    Dec 31 16:04:34 gumstix daemon.err ntpd[447]: time correction of
    -972551638 seconds exceeds sanity limit (1000); set clock manually to
    the correct UTC time.
    ....
    Mar 8 06:51:15 gumstix daemon.notice ntpd[467]: time reset
    -972551637.925997 s

    Now -972551637 = -31 years, approximately, so that's how the date is
    set to 1939
    from 1970. However, it is not a simple sign inversion: the correct
    time adjustment
    should be more like +37 years.

    I'm really stumped. Any light you can shed on this problem is much
    appreciated.

    Robert Dodier


  2. Re: ntpd sets clock to the year 1939

    Robert Dodier wrote:
    > Hello,
    >
    > I am working with embedded Linux systems (Gumstix) which appear to
    > lack
    > a persistent clock so whenever they are rebooted, their system clocks
    > go
    > back to January 1, 1970. I am hoping to use ntpd to set the clock on
    > these
    > systems but I am getting an unexpected result.
    >
    > When I run ntpd on the Gumstix, without the -g option it complains
    > that the
    > time difference between the local clock and the server is too great.
    > OK, I expected that. However, when I run it again with -g, ntpd
    > happily
    > makes a big adjustment in the local time ... changing it from 1970 to
    > 1939 for some reason. I tried a couple of different servers but got
    > the same
    > result.
    >
    > Here's the content of /etc/ntp.conf (sans most of the comments):
    >
    > restrict default nomodify notrap noquery
    > restrict 127.0.0.1
    > # server 0.pool.ntp.org
    > # server 1.pool.ntp.org
    > # server 2.pool.ntp.org
    > server time.cachenetworks.com
    > driftfile /var/lib/ntp/drift
    >
    > Here's the output from /var/log/messages.
    > The first output is without -g option and second one is with -g.
    > ...
    > Dec 31 16:04:34 gumstix daemon.err ntpd[447]: time correction of
    > -972551638 seconds exceeds sanity limit (1000); set clock manually to
    > the correct UTC time.
    > ...
    > Mar 8 06:51:15 gumstix daemon.notice ntpd[467]: time reset
    > -972551637.925997 s
    >
    > Now -972551637 = -31 years, approximately, so that's how the date is
    > set to 1939
    > from 1970. However, it is not a simple sign inversion: the correct
    > time adjustment
    > should be more like +37 years.
    >
    > I'm really stumped. Any light you can shed on this problem is much
    > appreciated.
    >
    > Robert Dodier
    >


    I believe that there is a limit to the date/time range that ntpd can
    handle and that it's something like 36 years. Try setting the date
    manually to something a little closer to being current. If it's off by
    less than 36 years, I think ntpd will handle it correctly. A startup
    script that set the date to a reasonable approximation; e.g. 2007 would
    probably solve your problem and work for the next 36 years or so.


  3. Re: ntpd sets clock to the year 1939

    On Mar 26, 12:50 pm, "Richard B. gilbert"
    wrote:

    > I believe that there is a limit to the date/time range that ntpd can
    > handle and that it's something like 36 years. Try setting the date
    > manually to something a little closer to being current. If it's off by
    > less than 36 years, I think ntpd will handle it correctly. A startup
    > script that set the date to a reasonable approximation; e.g. 2007 would
    > probably solve your problem and work for the next 36 years or so.


    Yes! That's it. I set the date by hand to Jan 1, 2007, and then ntpd
    was
    able to handle the rest. It seems odd to me that ntpd gets confused by
    too large a time difference, but oh well, it's OK the way it is.

    Thanks for your help,
    Robert Dodier


  4. Re: ntpd sets clock to the year 1939

    Robert Dodier wrote:
    > On Mar 26, 12:50 pm, "Richard B. gilbert"
    > wrote:
    >
    >
    >>I believe that there is a limit to the date/time range that ntpd can
    >>handle and that it's something like 36 years. Try setting the date
    >>manually to something a little closer to being current. If it's off by
    >>less than 36 years, I think ntpd will handle it correctly. A startup
    >>script that set the date to a reasonable approximation; e.g. 2007 would
    >>probably solve your problem and work for the next 36 years or so.

    >
    >
    > Yes! That's it. I set the date by hand to Jan 1, 2007, and then ntpd
    > was
    > able to handle the rest. It seems odd to me that ntpd gets confused by
    > too large a time difference, but oh well, it's OK the way it is.
    >
    > Thanks for your help,
    > Robert Dodier
    >


    It's hardly ever a problem since most systems have a hardware clock of
    some sort that can supply a reasonable starting point. In 2007, I don't
    think that 1970-is a reasonable starting point.


  5. Re: ntpd sets clock to the year 1939

    Richard B. gilbert wrote:
    []
    > It's hardly ever a problem since most systems have a hardware clock of
    > some sort that can supply a reasonable starting point. In 2007, I
    > don't think that 1970-is a reasonable starting point.


    Whilst I have some sympathy for that viewpoint, NTP should not today have
    that 30-year limitation (delighted to hear it is being extended).

    It is not a defect of the OS that it allows its real-time clock to be set
    /before/ the base time - 1970?

    David



  6. Re: ntpd sets clock to the year 1939

    David J Taylor wrote:
    > Richard B. gilbert wrote:
    > []
    >
    >>It's hardly ever a problem since most systems have a hardware clock of
    >>some sort that can supply a reasonable starting point. In 2007, I
    >>don't think that 1970-is a reasonable starting point.

    >
    >
    > Whilst I have some sympathy for that viewpoint, NTP should not today have
    > that 30-year limitation (delighted to hear it is being extended).
    >
    > It is not a defect of the OS that it allows its real-time clock to be set
    > /before/ the base time - 1970?
    >
    > David
    >
    >


    The "30-year" limitation is really, I believe, 36 years. It's a
    artifact of the data structures used by the current implementation; a
    sixty-four bit word with the binary point in the middle is used to
    represent the seconds and fractional seconds since 1-JAN-1970. This has
    served us well for the last 20 years or so. I believe that the new
    standard is going to call for a 128 bit word which should last a few
    years longer. :-)

    The fault, if any, is the way Unix keeps time. I believe it's a signed
    32 bit integer keeping seconds since 1-JAN-1970. Digital's VMS used a
    scheme that could represent any time from a base time in November 1857
    through the next 30,000 years or so. Unix time, at least until
    recently, would overflow in 2036.




  7. Re: ntpd sets clock to the year 1939

    On Mon, 26 Mar 2007 19:01:00 -0400, "Richard B. gilbert"
    wrote:

    >Robert Dodier wrote:
    >> On Mar 26, 12:50 pm, "Richard B. gilbert"
    >> wrote:
    >>
    >>
    >>>I believe that there is a limit to the date/time range that ntpd can
    >>>handle and that it's something like 36 years. Try setting the date
    >>>manually to something a little closer to being current. If it's off by
    >>>less than 36 years, I think ntpd will handle it correctly. A startup
    >>>script that set the date to a reasonable approximation; e.g. 2007 would
    >>>probably solve your problem and work for the next 36 years or so.

    >>
    >>
    >> Yes! That's it. I set the date by hand to Jan 1, 2007, and then ntpd
    >> was
    >> able to handle the rest. It seems odd to me that ntpd gets confused by
    >> too large a time difference, but oh well, it's OK the way it is.
    >>
    >> Thanks for your help,
    >> Robert Dodier
    >>

    >
    >It's hardly ever a problem since most systems have a hardware clock of
    >some sort that can supply a reasonable starting point. In 2007, I don't
    >think that 1970-is a reasonable starting point.


    "Be liberal in what you accept, conservative in what you send."

    We may not think that 1970 is a reasonable starting point, but these systems
    exist today and ntpd should deal gracefully with them. In fact, a POSIX time of
    0 is not exactly an unreasonable starting date for a system with no hardware
    clock and no DHCP-specified NTP server.

    It's unfortunate that applications (especially an application dedicated to
    keeping the correct time, fer cryin out loud) fall over when faced with such a
    time value, but whose fault is that?



  8. Re: ntpd sets clock to the year 1939

    Marc Brett wrote:
    > On Mon, 26 Mar 2007 19:01:00 -0400, "Richard B. gilbert"
    > wrote:
    >
    >
    >>Robert Dodier wrote:
    >>
    >>>On Mar 26, 12:50 pm, "Richard B. gilbert"
    >>>wrote:
    >>>
    >>>
    >>>
    >>>>I believe that there is a limit to the date/time range that ntpd can
    >>>>handle and that it's something like 36 years. Try setting the date
    >>>>manually to something a little closer to being current. If it's off by
    >>>>less than 36 years, I think ntpd will handle it correctly. A startup
    >>>>script that set the date to a reasonable approximation; e.g. 2007 would
    >>>>probably solve your problem and work for the next 36 years or so.
    >>>
    >>>
    >>>Yes! That's it. I set the date by hand to Jan 1, 2007, and then ntpd
    >>>was
    >>>able to handle the rest. It seems odd to me that ntpd gets confused by
    >>>too large a time difference, but oh well, it's OK the way it is.
    >>>
    >>>Thanks for your help,
    >>>Robert Dodier
    >>>

    >>
    >>It's hardly ever a problem since most systems have a hardware clock of
    >>some sort that can supply a reasonable starting point. In 2007, I don't
    >>think that 1970-is a reasonable starting point.

    >
    >
    > "Be liberal in what you accept, conservative in what you send."
    >
    > We may not think that 1970 is a reasonable starting point, but these systems
    > exist today and ntpd should deal gracefully with them. In fact, a POSIX time of
    > 0 is not exactly an unreasonable starting date for a system with no hardware
    > clock and no DHCP-specified NTP server.
    >
    > It's unfortunate that applications (especially an application dedicated to
    > keeping the correct time, fer cryin out loud) fall over when faced with such a
    > time value, but whose fault is that?
    >
    >


    The opposite argument would be that it's not reasonable for ntpd to make
    a "leap of faith" and jump the time by 36 years! Ntpd is designed to
    consider a clock that's off by 1024 seconds or more as a situation it is
    not equipped to handle. Ntpd is behaving as it's designed and
    documented to behave.

    The source is available and anyone with the necessary skills can modify
    it to handle special cases like this. Anyone lacking the necessary
    skills can pay someone with the skills to do the work.


  9. Re: ntpd sets clock to the year 1939

    On Tue, 27 Mar 2007 11:04:02 -0400, "Richard B. gilbert"
    wrote:

    >Marc Brett wrote:
    >> On Mon, 26 Mar 2007 19:01:00 -0400, "Richard B. gilbert"
    >> wrote:
    >>>Robert Dodier wrote:
    >>>>On Mar 26, 12:50 pm, "Richard B. gilbert"
    >>>>wrote:
    >>>>>I believe that there is a limit to the date/time range that ntpd can
    >>>>>handle and that it's something like 36 years. Try setting the date
    >>>>>manually to something a little closer to being current. If it's off by
    >>>>>less than 36 years, I think ntpd will handle it correctly. A startup
    >>>>>script that set the date to a reasonable approximation; e.g. 2007 would
    >>>>>probably solve your problem and work for the next 36 years or so.
    >>>>
    >>>>Yes! That's it. I set the date by hand to Jan 1, 2007, and then ntpd
    >>>>was
    >>>>able to handle the rest. It seems odd to me that ntpd gets confused by
    >>>>too large a time difference, but oh well, it's OK the way it is.
    >>>
    >>>It's hardly ever a problem since most systems have a hardware clock of
    >>>some sort that can supply a reasonable starting point. In 2007, I don't
    >>>think that 1970-is a reasonable starting point.

    >>
    >> "Be liberal in what you accept, conservative in what you send."
    >>
    >> We may not think that 1970 is a reasonable starting point, but these systems
    >> exist today and ntpd should deal gracefully with them. In fact, a POSIX time of
    >> 0 is not exactly an unreasonable starting date for a system with no hardware
    >> clock and no DHCP-specified NTP server.
    >>
    >> It's unfortunate that applications (especially an application dedicated to
    >> keeping the correct time, fer cryin out loud) fall over when faced with such a
    >> time value, but whose fault is that?

    >
    >The opposite argument would be that it's not reasonable for ntpd to make
    >a "leap of faith" and jump the time by 36 years!


    But 26 years, say, is perfectly reasonable?

    >Ntpd is designed to
    >consider a clock that's off by 1024 seconds or more as a situation it is
    >not equipped to handle. Ntpd is behaving as it's designed and
    >documented to behave.


    But it isn't. The "ntpd -g" documentation says:

    -g
    Normally, ntpd exits with a message to the system log if the offset exceeds the
    panic threshold, which is 1000 s by default. This option allows the time to be
    set to any value without restriction; however, this can happen only once.

    "Without restriction" means, to me, that time jumps of 26 years, 36 years, or 46
    years are all perfectly fine.

    >The source is available and anyone with the necessary skills can modify
    >it to handle special cases like this. Anyone lacking the necessary
    >skills can pay someone with the skills to do the work.


    Maybe the gumstix folk can be persuaded...


  10. Re: ntpd sets clock to the year 1939

    On Mar 27, 9:04 am, "Richard B. gilbert"
    wrote:

    > >>It's hardly ever a problem since most systems have a hardware clock of
    > >>some sort that can supply a reasonable starting point. In 2007, I don't
    > >>think that 1970-is a reasonable starting point.


    I dunno. Zero is a pretty common default value.
    I'm not surprised the device I'm working with boots up with that date.

    > The opposite argument would be that it's not reasonable for ntpd to make
    > a "leap of faith" and jump the time by 36 years!


    No need for a leap of faith. Jumps larger than the sanity limit
    are authorized by the -g option.

    > Ntpd is designed to consider a clock that's off by 1024 seconds or
    > more as a situation it is not equipped to handle.


    Except as modified by the -g option. Let's see what the man page
    for ntpd says about that:

    -------------- begin quoted text about ntpd -g --------------
    Normally, ntpd exits if the offset exceeds the sanity limit, which is
    1000 s by default. If the sanity limit is set to zero, no sanity
    checking
    is performed and any offset is acceptable. This option overrides the
    limit and allows the time to be set to any value without restriction;
    however, this can happen only once. After that, ntpd will exit if
    the
    limit is exceeded. This option can be used with the -q option.
    --------------- end quoted text about ntpd -g ---------------

    It says "any offset", not "any offset less than 30 years".

    > Ntpd is behaving as it's designed and documented to behave.


    I don't know about the design, but in fact it's documented to behave
    otherwise.I searched the ntp documentation and could not find any
    mention of the 30-year limitation. It certainly should be in the man
    page for ntpd, if it's anywhere.

    > The source is available and anyone with the necessary skills can modify
    > it to handle special cases like this. Anyone lacking the necessary
    > skills can pay someone with the skills to do the work.


    Or someone lacking necessary skills can make noise about it
    and hope than someone else will get motivated to work on it.
    Other people do this to me all the time. I don't see anything
    wrong with it. It's often called a request for enhancement.

    But maybe it would be enough to just mention the 30 year
    limitation in the documentation.

    FWIW
    Robert Dodier


  11. Re: ntpd sets clock to the year 1939

    Robert Dodier wrote:
    > On Mar 27, 9:04 am, "Richard B. gilbert"
    > wrote:
    >
    >
    >>>>It's hardly ever a problem since most systems have a hardware clock of
    >>>>some sort that can supply a reasonable starting point. In 2007, I don't
    >>>>think that 1970-is a reasonable starting point.
    >>>

    >
    > I dunno. Zero is a pretty common default value.
    > I'm not surprised the device I'm working with boots up with that date.
    >
    >
    >>The opposite argument would be that it's not reasonable for ntpd to make
    >>a "leap of faith" and jump the time by 36 years!

    >
    >
    > No need for a leap of faith. Jumps larger than the sanity limit
    > are authorized by the -g option.
    >


    Did you start it with the -g option?

    >
    >>Ntpd is designed to consider a clock that's off by 1024 seconds or
    >>more as a situation it is not equipped to handle.

    >
    >
    > Except as modified by the -g option. Let's see what the man page
    > for ntpd says about that:
    >
    > -------------- begin quoted text about ntpd -g --------------
    > Normally, ntpd exits if the offset exceeds the sanity limit, which is
    > 1000 s by default. If the sanity limit is set to zero, no sanity
    > checking
    > is performed and any offset is acceptable. This option overrides the
    > limit and allows the time to be set to any value without restriction;
    > however, this can happen only once. After that, ntpd will exit if
    > the
    > limit is exceeded. This option can be used with the -q option.
    > --------------- end quoted text about ntpd -g ---------------
    >
    > It says "any offset", not "any offset less than 30 years".
    >
    >
    >>Ntpd is behaving as it's designed and documented to behave.

    >
    >
    > I don't know about the design, but in fact it's documented to behave
    > otherwise.I searched the ntp documentation and could not find any
    > mention of the 30-year limitation. It certainly should be in the man
    > page for ntpd, if it's anywhere.
    >


    Then perhaps the documentation needs to be updated! The 36 year "epoch"
    (if that's the proper term) has been discussed before on this
    newsgroup although not recently. Perhaps because it's rare for anyone
    to start ntpd with a clock that's off by 37 years! I think you may be
    the only person to report such a problem in the four years or so that
    I've been reading this newsgroup!

    Perhaps a startup script that sets the date to 1-JAN-2007 before
    starting ntpd would put a band-aid on the problem.







  12. Re: ntpd sets clock to the year 1939

    If you do not like the X year limit at startup I recommend you lobby for
    something more to your liking.

    I think there are 2 places to lobby:

    - Dave
    - The IETF NTP WG

    I believe Dave's point is that this is trivial to work around - one sets the
    initial date to be either somewhere between the time the executable was
    compiled and X years *later* - then ntpd starts up and sets the date
    correctly. In fact, it will do that for the next X+60ish (unless it's
    X+30ish) years.

    I would *love* to see the spec include a flag (could be the stratum, could
    be something else) that says "The date you are being given is not X.Y
    (seconds and fractions of seconds), but is X (all seconds)". This will, I
    believe, solve the problem without making the packets bigger.

    H

  13. Re: ntpd sets clock to the year 1939

    On Mar 27, 3:05 pm, Harlan Stenn wrote:

    > I believe Dave's point is that this is trivial to work around -


    It is trivial *once you know it must be done*.
    As it stands, ntpd -g happily sets an incorrect date, and there
    is no way to know from reading the available documentation or
    the program output that there is anything amiss.

    At this point all I want is to mention the limitation in the man page.

    Robert Dodier


  14. Re: ntpd sets clock to the year 1939

    Richard B. gilbert wrote:
    > Then perhaps the documentation needs to be updated! The 36 year "epoch"
    > (if that's the proper term) has been discussed before on this
    > newsgroup although not recently. Perhaps because it's rare for anyone
    > to start ntpd with a clock that's off by 37 years! I think you may be
    > the only person to report such a problem in the four years or so that
    > I've been reading this newsgroup!


    Can we at least use the right numbers? It was 34 years and now is 68
    years. Calculate 2^31 seconds from 1-1-1970.

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  15. Re: ntpd sets clock to the year 1939

    Danny Mayer wrote:
    > Richard B. gilbert wrote:
    >
    >>Then perhaps the documentation needs to be updated! The 36 year "epoch"
    >> (if that's the proper term) has been discussed before on this
    >>newsgroup although not recently. Perhaps because it's rare for anyone
    >>to start ntpd with a clock that's off by 37 years! I think you may be
    >>the only person to report such a problem in the four years or so that
    >>I've been reading this newsgroup!

    >
    >
    > Can we at least use the right numbers? It was 34 years and now is 68
    > years. Calculate 2^31 seconds from 1-1-1970.
    >


    Danny,

    Please! I'm lucky to be able to count to twenty with my shoes on!
    Trying to calculate the number of seconds elapsed from 1970 to now is
    completely beyond me. If I got my computer to do it, I still wouldn't
    know if the answer was right. Leap years+leap seconds. . . . .
    Forget it.

    I'd write 34 on a post-it and paste it on my monitor but it would
    probably fall off by itself before I needed it again.



+ Reply to Thread