Failure of ntpdate if the system is set to a date beyond 2038

Question

The correct current date is .Fri Mar 25 12:11:07 CST 2016.

When I change the date to "2018/01/01", ntpdate works properly.

When I change the date to "2099/01/01", ntpdate does not work properly.

Ok:

[root@oldboylinux ~]# date -s "2018/01/01"
Mon Jan  1 00:00:00 CST 2018

[root@oldboylinux ~]# /usr/sbin/ntpdate time.nist.gov
25 Mar 12:06:22 ntpdate[7187]: step time server 216.229.0.179 offset -55857225.378947 sec

Not ok:

[root@oldboylinux ~]#date -s "2099/01/01"
Thu Jan  1 00:00:00 CST 2099

[root@oldboylinux ~]# /usr/sbin/ntpdate time.nist.gov
 1 May 18:36:59 ntpdate[7189]: step time server 216.229.0.179 offset 1682966210.024232 sec

Mon May 1 18:41:18 CST 2152 is a wrong date.

Does ntpdate have an effective range?

Answer 1

First some notes:

• Current version of NTP (v4) operates using eras.

• One era is 136 years, (seconds presentable by an unsigned 32-bit integer). Or roughly

    60 * 60 * 24 * 365 * 136 = 4288896000 
                        2^32 = 4294967296
  
    4294967296 − 4288896000 = 6071296
     6071296 / 60 / 60 ∕ 24 ≈ 70 (days, not accounting for leaps)
  

• Era 0: The prime epoch, or base date of "era 0", is 00:00 1 Jan 1900 UTC.

• Era 1: starts sometime at the beginning of year 2036. (Two years prior to UNIX-2038)

• Era 2: starts sometime at the beginning of year 2172.

• etc. (For some other examples have a look at page 14 of RFC 5905.)

• ntpdate use NTP time stamps which are 64-bits. 32-bit for seconds and 32-bit for fractions.

• A bit confusing perhaps; NTP-date uses 128-bits and include era. This spans the age of the universe and far into the future.

As stated in the NTP section of the "Year 2038 problem"-Wikipedia page you have an absolute limit of 68 years between two NTP-timestamps. (136 / 2 = 68). Though, to eliminate ambiguity, one should use a more narrow band.

NTP time stamps operates referencing the relative and not absolute time; The server provides a correction to the client by a relative offset to its own time. I.e.: It does not say:

— The date is 26th of March 2016

but rather (simplified as how to NTP works):

— You are off by +123412512.918 seconds, or:
— You are off by -2652221.3466 seconds, etc.

Or to quote from the RFC:

Timestamps are unsigned values, and operations on them produce a result in the same or adjacent eras. Era 0 includes dates from the prime epoch to some time in 2036, when the timestamp field wraps around and the base date for era 1 is established.

In your case when you have the year 2099, you are more then 68 years in the future - approximately 15 years. You end up in year 2152 and what we have is:

 2152 - 2016 = 136 (One era)

Or put another way:

                    2099 - 2036 = 63          (years into era 1)
        63 * 365 * 24 * 60 * 60 = 1986768000  (approx NTP time stamp for 2099)
       116 * 365 * 24 * 60 * 60 = 3658176000  (approx NTP time stamp for 2016)
       3658176000 - 1986768000  = 1671408000  (approx diff)
1671408000 / 60 / 60 / 24 / 365 = 53          (approx years)

1986768000 < 3658176000 thus add 1671408000

2099 + 53 = 2152 (the year your system was corrected to)

So, yes, to answer your question:

— Does ntpdate have an effective range?

Yes. ± 68 years, though the maximum effective range is somewhat narrower.

NTP in it self is infinite.

Have a look at RFC 5905 if interested. Also note that obsoleted RFCs can hold interesting information, such as Appendix E. The NTP Timescale and its Chronometry in RFC 1305.

---

(P.S: In comparison with UNIX-timestamps, 1970 + 68 = 2038.)

Answer 2

What are you seeing is the common "bug" known as the year 2038 problem, aka the Y2K38 bug, that is still present in 32-bit Linux servers.

By around the year 2000, we became aware that besides the y2k/millenium bug, there would be another time-related bug further down the road. (yeah, I was part of a y2k "prevention" team)

As the Unix epoch is a 32 bit-second counter that started in 1st of January of 1970, and was only a signed 32-bit integer, it had (and still has in some systems), an upper limit of 03:14:07 UTC on 19 January 2038. https://en.wikipedia.org/wiki/Year_2038_problem

In latest implementations it has been widened to 64 bits.

Starting with NetBSD version 6.0 (released in October 2012), the NetBSD operating system uses a 64-bit time_t for both 32-bit and 64-bit architectures. Applications that were compiled for an older NetBSD release with 32-bit time_t are supported via a binary compatibility layer, but such older applications will still suffer from the Year 2038 problem.[13]

OpenBSD since version 5.5, released in May 2014, also uses a 64-bit time_t for both 32-bit and 64-bit architectures. In contrast to NetBSD, there is no binary compatibility layer. Therefore, applications expecting a 32-bit time_t and applications using anything different from time_t to store time values may break.[14]

Linux uses a 64-bit time_t for 64-bit architectures only; the pure 32-bit ABI is not changed due to backward compatibility.[15] There is ongoing work, mostly for embedded Linux systems, to support 64-bit time_t on 32-bit architectures, too

As a folklore history and a quite elaborate hoax, John Titor was sent back in time to get a mainframe to help correct legacy problems in the future due to the 2038 bug, and forecasted an American civil/nuclear war under the rule of Hillary Clinton in a parallel reality of ours.

http://www.strangerdimensions.com/2011/10/03/john-titor-the-ibm-5100/

John Titor’s story began in the year 2036. Titor belonged to a team of seven individuals selected to embark on a journey through time. He had lived through unimaginable horrors in a world destroyed by selfishness, cynicism, and corrupt government, ravaged by nuclear war. To make matters worse, what little remained of their technology was threatened by a looming UNIX timeout error in 2038.

Please do see also https://en.wikipedia.org/wiki/9223372036854775807

Systems employing a 32-bit type are susceptible to the Year 2038 problem, so many implementations have moved to a wider 64-bit type, with a maximal value of 263−1 corresponding to a point in time 292 billion years from now.

So coming back to your ntpdate question.

About the 2038 limit. So the problem is that time_t was (is) a 32-bit signed int. i.e. a 32 bit integer with the last bit dedicated to signal. So, in effect you can it can only store numbers (then number of seconds between -0x7fffffff and +7fffffff (+2147483647). So +2147483647 limits the representation of the time interval to 1 January 1970+2147483647 seconds which translates to ntpdate being only able to store in your system dates until 03:14:07 UTC on 19 January 2038.

About dates after 2038, the problem is the code routines converting strings to the internal representation (time_t/32 bit integer) wrap around or are simply reset to the day/0 second depending on library implementation.

About your upper limit year. time_t in your system is a signed integer, so the library is making the upper limit check as the value of an unsigned integer, which at +4294967295 seconds after January 1, 1970 will give it an upper limit somewhere around year 2106. Depending on implementation, the check may actually being done in string more or the behaviour is due to the properties of the 32 bit integer, only checking ntpdate code.

INT_MAX (32 bits) = 2147483647
UINT_MAX (32 bits) = 4294967295 (0xffffffff)

From https://en.wikipedia.org/wiki/Year_2038_problem

For example, changing time_t to an unsigned 32-bit integer, which would extend the range to the year 2106, would adversely affect programs that store, retrieve, or manipulate dates prior to 1970, as such dates are represented by negative numbers

As a last footnote, be aware that a system can lack y2k38 compliance both in the system/OS code and in the RTC clock.

At the OS level, going to a 64-bit linux (if the architecture allow it) will fix it now, or hopefully 32-bit Linux will fix it in a near future.

As for the RTC in older machines, that means you will get the data garbled after 2038, at least in logs until ntpd kicks in and corrects system date.