Time Synchronization and Rollovers

A rollover always occurs when a number that is incremented in regular intervals exceeds some upper limit, and count starts again from the lowest possible value. This causes an ambiguity that can only be solved if you know how often this overflow has taken place.

For example, if you have a two-digit year number (year of the century) with the value “50”, you have to determine the century to determine whether the short year number refers to the year 1950, e.g. a date of birth, or the year 2050, e.g. when a contract is about to expire.

Similar problems exist in the way operating systems count the time, and in some protocols used to synchronize the system time.

The popular GPS week number rollover is a similar case that is explained by a different KB article.

The system time of most UNIX-like systems is based on the POSIX specification, which simply counts the number of seconds since an epoch, where the epoch is 1970-01-01 00:00:00 in most cases.

If a 64 bit number is used to count the seconds, a rollover will only occur 292277000000 years or so after the epoch.

However, many 32 bit operating systems that are POSIX compatible only use a native 32 bit signed number to count the seconds and store time stamps. These counters and time stamps will overflow on 2038-01-19 so that after this date the system will no longer function properly.

This is commonly known as The Y2038 Problem.

There are systems where a different epoch is being used. For such systems, the rollover occurs at a different date.

Modern Linux versions running on servers and desktop machines are 64 bit systems and thus use 64 bit time stamps, so there is no Y2038 problem for these systems.

However, there are many embedded or IoT devices running 32 bit Linux systems because the hardware is not 64 bit compatible.

For 32 bit Linux there has been ongoing work to use a 64 bit counter for the system time and associated time stamps, too. However, this is much trickier than it sounds. The native 32 bit time stamps are used in many API calls and even inside some file systems, so simply changing the time stamps from 32 bit to 64 bit would totally break compatibility.

Starting with kernel 5.6, there is compatible support for 64 bit time stamps in 32 bit Linux. This required the use of new API calls, which in turn requires that all applications are recompiled with specific “compatibility” settings, and that the compiler and associated runtime libraries are current enough to support the new APIs.

Since Windows NT, Windows uses a 64 bit FILETIME structure to represent the system time. The FILETIME structure counts the 100 ns units since 1601-01-01 00:00:00 and won't rollover before year 30000 or so.

The conversion from FILETIME to a POSIX time stamp (i.e., seconds since 1970) is done by the runtime library shipped with a particular compiler.

Visual Studio compilers from Microsoft (at least VS2005 or later) use a 64 bit type for POSIX time stamps, and provide appropriate conversion routines even on 32 bit Windows versions, so neither the system time nor applications using POSIX time stamps that have been built with VS2005 or later should rollover in 2038.

The NTP protocol up to NTPv4 uses unsigned 32 bit numbers for the 'seconds' part of the UTC time stamps in the network packets, and the epoch from which seconds are counted is 1900-01-01 00:00::00.

So the seconds of those NTP time stamps will already roll over after 2036-02-07 06:28:15.

Please note this is due to the data format of the NTP network packets, regardless whether the operating system and application are 32 bit, or 64 bit.

The NTP specifications know the concept of an era number. Until the rollover in 2036, we have NTP era 0, with high second numbers, and after the rollover we'll have NTP era 1, with seconds starting again at low numbers.

Unfortunately, up to NTP protocol version 4, the era number is not transmitted in the NTP network packets. So, assuming the NTP server sends the appropriate second counts before and after the rollover, it is is the task of the NTP client to determine and apply the correct era number to determine a correct date after 2036-02-07.

Details of the era handling in ntpd can be found here:

• https://www.eecis.udel.edu/~mills/y2k.html

Please note that whether this works or not depends on the implementation of the NTP software running on the NTP server but also the software running on the NTP client.

For the NTP software from ntp.org, this has been successfully tested quite some time ago by one of the maintainers of the project.

A potential problem with embedded devices is that they often don't provide a battery-buffered real time clock (RTC), which can make it difficult as NTP client to determine the correct NTP era. A potential workaround can be to set the initial system date e.g. to the release date of the firmware.

For the time synchronization of the NTP clients, please keep in mind:

• It is important that the NTP software running on the client supports the NTP era concept, and can properly determine the era number.

• Whether the NTP rollover is handled correctly, or not, also depends strongly on the system clock implementation of the client operating system.

• Even if the NTP rollover is handled correctly, the client may still suffer from the Y2038 problem.

The PTP protocol supports 48 bit TAI time stamps, so generally, they won't rollover soon.

However, even PTP implementations running on 32 bit operating systems need to create a full 48 bit time stamp when sending a packet, and evaluate the full 48 bit time stamps when receiving a packet.

And of course, similar to NTP, this can only work if the client doesn't suffer from the Y2038 problem.

All Meinberg LANTIME devices except the SyncFire models are based on 32 bit hardware. Meinberg is currently working to implement full 64 bit timestamp support in all parts of the firmware, but it will still take some time until everything has been implemented and thoroughly tested.

The current firmware versions will work properly until 2038.

Please note that generally, the whole time synchronization chain needs to support proper operation after Y2038, and the firmware on the time server (including NTP and PTP services) is only one piece of the chain.

The requirements at the server side can be implemented and tested by Meinberg:

• Evaluation of reference time sources (GPS/GNSS, DCF77, IRIG-like time codes)

• Operating system and NTP/PTP services at the server side

However, customers have to make sure that also the client side works as expected:

• PTP clients use full 48 bit time stamps

• NTP client software can determine and account for the NTP era

• The client OS doesn't suffer from Y2038 problems

— Martin Burnicki martin.burnicki@meinberg.de, last updated 2021-08-26