Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Is time() guaranteed to be leap-second aware?

PHP manual states that time() returns "the current UNIX timestamp"  ­and microtime() returns the "current Unix timestamp with microseconds" ʙ.

However, are these functions guaranteed to behave like that of strictly conforming POSIX.1 systems?

Specifically, do leap seconds get inserted in such a way that the output of time() | ­microtime() jump backwards by 1 second at the start of the next day, (which is the also at the end of the leap second,) giving us repeated return values —as opposed to fresh unique values— throughout the entirety of the first second of that next day?

For example, if we poll time() | ­microtime() every microsecond throughout the span of 1998-12-31 and 1999-01-01, would there be two occurences of each value within the range 915 148 800 <= x < 915 148 801?

like image 527
Pacerier Avatar asked Oct 15 '11 20:10

Pacerier


People also ask

How are leap seconds determined?

The average speed of Earth's rotation is measured by Universal Time (UT1). When the difference between UTC and UT1 is predicted to reach 0.9 seconds within 12 months, a leap second is added to UTC and clocks worldwide. In other words, our clocks are always kept within a second of the average length of a day.

Does Python datetime handle leap seconds?

Unlike the time module, the datetime module does not support leap seconds.

Does UTC time include leap seconds?

Coordinated Universal Time (UTC) is based on International Atomic Time (TAI), but it is adjusted by leap seconds to account for the difference between the definition of the second and the rotation of Earth.

Does Unix time include leap seconds?

Unix time is the number of seconds that have elapsed since 00:00:00 UTC on 1 January 1970, excluding leap seconds. This time is named the Unix epoch, because it is the start of the Unix time.


2 Answers

The UNIX timestamp, as you get it from time() in PHP, is a peculiar beast.

It took me a long time to understand this, but what happens is that the timestamp increases during the leap second, and when the leap second is over, the timestamp (but not the UTC!) jumps back one second.

This has some important implications:

  • You can always accurately convert from UTC to a UNIX timestamp
  • You can not always (for all points in time) convert from timestamp to UTC
  • Unix timestamp is non-contiguous, i.e. it steps back. (Or alternatively, it stays the same without incrementing for 2 seconds.)
  • If you get a conversion error converting from UNIX timestamp to UTC, the error will be at most 2 seconds off. (This means you could get the wrong day though.)
  • In retrospect, the Unix timestamp will appear linear. This means that if you are storing time series data and you are not concerned with a single second or two per year being incorrectly represented, then you can consider stored timestamped data contiguous.

Workarounds

What if the Unix timestamp neither jumped backed abruptly nor stayed the same for 2 seconds? This is exactly what Google has made happen for their servers. Their solution was to slowly skew the time merely milliseconds at a time over a long period of time, to make the leap second shift virtually invisibly to applications. (As far as the applications and operating systems on Google servers are concerned, leap seconds are no longer inserted by the IERS.)

like image 138
Prof. Falken Avatar answered Oct 16 '22 08:10

Prof. Falken


PHP is a serverside language. The time() function will resolve to the system time of that server. If the server is running an NTP daemon then it will be leap second aware and adjust accordingly. PHP has no knowledge of this, but the system does.

like image 10
Angelom Avatar answered Oct 16 '22 09:10

Angelom