[lambda]

Unix time is awful, since converting it to UTC is a real pain, as it doesn't count leap seconds which are included in UTC (thus, some seconds in Unix time are longer than others, or all of them are longer than standard SI seconds and the exact length fluctuates based on the introduction of leap seconds, or the like).

[jchavannes]

  leap seconds, or the like

What else other than leap seconds are you referring to? Leap seconds are a problem for all time storage since most time parsers consider second 61 invalid [1]. They also only happen about once a year. Google just pretends they don't exist [2].

Converting from epoch to the local timezone is supported in pretty much every language. I'm not sure why you think it's such a pain.

[1] https://dev.mysql.com/doc/refman/5.0/en/time-zone-leap-secon...

[2] http://googleblog.blogspot.com/2011/09/time-technology-and-l...

[lambda]

The "or the like" was the end of the list of ways in which you could model the divergence between Unix time and the number of SI seconds between January 1st 1970 UTC and the present.

One way of modelling it is as saying that seconds in Unix time all have the same length, that differs by some factor from SI seconds, though that factor changes every time a leap second is introduced.

Another way is to say that seconds don't all have constant length; some seconds have a different length than the rest of the seconds (like those in the hour or day leading up to a leap second, or even just that the one second before the leap second is twice as long as a regular second).

The "or the like" was just a hedge against other possible ways of describing this divergence that I hadn't described in that one quick sentence.

Pretending that leap seconds don't exist is all well and good if you have a completely closed system, but as soon as you try to synchronize with or compare timestamps with UTC, you'll start running into problems.

[mikehotel]

How is Google's leap smear idea pretending like leap seconds don't exist? As per your link, "The solution we came up with came to be known as the “leap smear.” We modified our internal NTP servers to gradually add a couple of milliseconds to every update, varying over a time window before the moment when the leap second actually happens."

[jchavannes]

From the article:

> Usually when a leap second is almost due, the NTP protocol says a server must indicate this to its clients by setting the “Leap Indicator” (LI) field in its response. [..] Rather than doing this, we applied a patch to our internal NTP servers to not set LI, and tell a small “lie” about the time, modulating this “lie” over a time window w before midnight