On 2011-09-16 22:46, Daniel R. Tobias observed Google's lack of compliance with international standards:
On 16 Sep 2011 at 10:54, Poul-Henning Kamp wrote:
> Well, Googles hack is a workaround for internal use with no regard > to subsecond interoperability with anybody else.
That's typical of Google's general philosophy, where they value their services functioning smoothly over strict compliance with external standards; for instance, "web purist geeks' find it infuriating that Google's HTML fails to validate, but they're more interested in shaving off a few bytes by doing things like omitting quotes around attributes even where the standards require them, so long as all known browsers render the page correctly.
There simply is no standard modification of UTC that is a monotone function of TAI, and which is N times continuously differentiable for some N >= 0. Instead, there are several such modifications, used or propsed, such as Google's, the SLS time scale of Markus Kuhn, the modification in SOFA, and the time_t values in UNIX-like operating systems, each especially designed for their usage. Google needed a modification of UTC that could be used as the steering input for an ensemble of clocks. This requires a signal that is at least two times differentiable, like the signal of a clock that is not subject to sudden changes in rate. I find it clever from the Google engineers that they realized that the smoothness of the steering clock must be controlled, and that the the maximal deviation in rate is a secondary concern that is best left to a parameter of the solution. As long as that window size is less than the distance between successive leap seconds, UTC[Google] is well-defined -- eg, when UTC was 2008-12-31T23:59:60 (beginning of a "positive leap second"), UTC[Google] was 2008-12-31T23:59:59. I have never seen an equally clear statement for the value of type time_t to be returned by POSIX calls of time(), even with parameters left unspecified. Michael Deckers. _______________________________________________ LEAPSECS mailing list [email protected] http://six.pairlist.net/mailman/listinfo/leapsecs
