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

Question

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?

Psalmbook

How many seconds have you spent on this? – Immortelle

@Ash: cute but informative... haha – Injury

@Ash do you mean SI seconds or solar seconds? – Psalmbook

PHP gets the time from the system it runs on, so I suppose this will depend on the operating system. – Transonic

Check this post from Google, they figured a great way to do it: googleblog.blogspot.com/2011/09/… – Nothing

Answer 1

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.

Augury

Answer 2

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.)

Alisiaalison

@Prof., Would Angelom's answer be more accurate though? That it's dependent on the platform? – Psalmbook

@Pacerier, not exactly the platform but PHP depends on the time on the operating system to be correctly configured. – Alisiaalison

Answer 3

time() just returns the UNIX-Timestamp. This means, that it is not affected by leap seconds (and such), because you will never "lose" time, just because someone decided it. Only textual representations (e.g. created using date()) are affected.

Atory

I guess the question should be; is date() leap second aware? – Callihan

@King Am I misunderstanding something, because UNIX time is affected by leap seconds: en.wikipedia.org/wiki/Unix_time – Psalmbook

It's true that the Unix timestamp is not aware of leap seconds, but that also means that textual representations of the timestamp cannot be aware of them either, since there is no way to distinguish between the leap second and the second before/after it. – Transonic

@Psalmbook The Wikipedia article says the exact opposite: "...defined as the number of seconds elapsed since midnight Coordinated Universal Time (UTC) of January 1, 1970, not counting leap seconds." – Transonic

@Juhana: Sounds a little bit crazy, but it seems Pacerier is right... Must say, didn't know that. However, in your argumentation it would be impossible to convert an ISO- to an UNIX-timestamp, but the other way round would always be possible, because every UNIX-timestamp second is unique. – Atory

@Juhana: "When a leap second is inserted (which has occurred on average once every year and a half), the Unix time number increases continuously during the leap second, during which time it is more than 86 400 s since the start of the current day, and then jumps down by 1 at the end of the leap second, which is the start of the next day." – Atory

Ok, I see we might have different definitions for the word "affect". – Transonic