Slashdot Mirror
Google's New Public NTP Servers Provide Smeared Time (googleblog.com)
Google says it has built support for the leap second into the time servers that regulate all Google services. An anonymous reader shares a blogpost by Google:No commonly used operating system is able to handle a minute with 61 seconds, and trying to special-case the leap second has caused many problems in the past. Instead of adding a single extra second to the end of the day, we'll run the clocks 0.0014% slower across the ten hours before and ten hours after the leap second, and "smear" the extra second across these twenty hours. For timekeeping purposes, December 31 will seem like any other day. All Google services, including all APIs, will be synchronized on smeared time, as described above. You'll also get smeared time for virtual machines on Compute Engine if you follow our recommended settings. You can use non-Google NTP servers if you don't want your instances to use the leap smear, but don't mix smearing and non-smearing time servers.
Given that Terrestrial Time exists for astronomers, and the only people for whom leap seconds are useful are astronomers, can we just stop putting leap seconds into UTC?
I am TheRaven on Soylent News
The problem is not so much with UTC but with unix time, as POSIX and NTP have conflicting conventions for handling leap seconds. Well and Google NTP has yet another convention. But the spirit of what you say is correct, we should probably abandon unix time as the fundamental representation on computers in favor of TAI. Software already has to consult a timezone database to convert to local time anyway, why not also require that for conversion to UTC too (to get the leap second offset from TAI).
Just make the stocks trade in time-coordinated batches. The batches can still be relatively fast - even every second - just so it is slow enough to stop the stupid games with the speed of communications.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
It's funny to me that they say the Earth's rotation is "determined" by IERS. No, it is *measured*. A subtle implied difference, but a critical one. The problem here is actually with unix time, not UTC. TAI as an alternative to unix time actually makes pretty decent sense. When was the last time you manually converted from seconds since epoch to day/month/year?
I think the point is that since time zones are actually updated more frequently for political purposes than leap seconds occur, it makes sense, for network-connected computers at least, to just stuff the leap seconds in the same distribution channels (already done actually) and abandon trying to hack around the clumsy (non-monotonically increasing) definition of unix time.
This.
Every trade that occurs within a given interval (I think 1 second is too short still, maybe a minute... or 1/4 hour, since that's often how long quotes are delayed for the average trader) trades at the same price for a given transaction type. The net effect on the market would be the same, we just wouldn't have, for example, two people placing SELL orders for a million shares of something at $100/share and one of them getting $190/share while the other only gets $10/share, which does currently happen.
APK quotes people (including myself) without context and should not be trusted. Just thought you should know.
There are mods to ntpd and the time conversion libraries that do this. System clock is in real seconds since epoch, you only need to worry about leap seconds when converting between system clock and display (wall) time, which also handles time zones and leap years and everything else weird. Anyone who is dividing by 86400 to convert system clock to years, days, hours, minutes, seconds is doing it wrong. You can still divide by 86400 (or 3600 or 60) to display roughly how many hours, minutes or days a particular interval was, of course.
NTP could support this, or an auxiliary protocol defined, to distribute time conversion table changes (so with leap seconds as well as legal changes to daylight savings or other time zone changes), and to update the current difference between TAI and UTC. This would be useful even if we end up dropping DST or leap second adjustments.
Currently TAI and UTC differ by 36 seconds. For "current time", simply having that value available is sufficient for most applications that don't store the system clock value, and any that do are most likely already using a proper time conversion library.
Simply adding the ability to retrieve the clock as either "unix time (UTC-based)" or "elapsed time (TAI-based)" and convert between the two and use either as input to the time conversion routines would make it simple to update existing programs and databases. At the same time, converting once and for all to a 64-bit signed time value for seconds would help immensely with the next big time-handling crisis in about 21 years.
I fear that Google is just papering over the problem and making things more difficult to properly solve.