Google's New Public NTP Servers Provide Smeared Time (googleblog.com)

Does this mean.... by The-Ixian · 2016-12-01 02:49 · Score: 3, Funny

Does this mean that my DPS will be slightly higher on December 31st?

--
My eyes reflect the stars and a smile lights up my face.

Re:Does this mean.... by Diss+Champ · 2016-12-01 02:53 · Score: 3, Funny

That depends largly on whether you play better or worse while drunk. The NTP server tweak will be a secondary effect at best.
Re:Does this mean.... by Anonymous Coward · 2016-12-01 02:55 · Score: 5, Funny

Does this mean that my DPS will be slightly higher on December 31st?
No. It means you'll lose a second of uptime.
Re:Does this mean.... by vel-ex-tech · 2016-12-01 03:07 · Score: 1

It's one of those places where you have to see how it works into your MinMax spreadsheet. If you're a tank, uptime gives a bonus to drawing aggro, so you'll want to use the non-smearing servers to get that extra second of uptime. On the other hand, glass cannons will want to use the smearing server to get the DPS bonus.
Re:Does this mean.... by fisted · 2016-12-03 00:31 · Score: 1

That depends on how many dicks per second you normally take. I doubt a single extra second makes much of a difference except if you're real fast.

--
CLI paste? paste.pr0.tips!

Bagels by Anonymous Coward · 2016-12-01 02:51 · Score: 0

Love me a good schmear

Not new, just a holiday reminder PSA by Anonymous Coward · 2016-12-01 02:56 · Score: 5, Informative

Google has been smearing leap seconds over NTP since 2011. This is a public reminder that Google NTP will be serving smear seconds because there is one coming.

Re:Not new, just a holiday reminder PSA by lgw · 2016-12-01 06:23 · Score: 2

Leap seconds: even less desirable than Daylight Saving Time.
Seriously, why do we put up with this shit. The precise details of the Earth's rotation just aren't that important, except to a few hundred professional telescope operators, who have a history of keeping time their own way anyhow.

--
Socialism: a lie told by totalitarians and believed by fools.
Re:Not new, just a holiday reminder PSA by jaa101 · 2016-12-01 10:19 · Score: 1

The precise details of the Earth's rotation just aren't that important, except to a few hundred professional telescope operators
My guess is that there are way more navigators than astronomers who need accurate time. Navigation is essential for safety. Sure, celestial navigation is only a backup for GPS these days but I think we'd all prefer that there was a backup available. The US Navy certainly thinks so. At the equator, four seconds makes a difference of one nautical mile.
The US has been pushing for the abandonment of leap seconds for some years but has so far failed to have the standard changed.
Re:Not new, just a holiday reminder PSA by Anonymous Coward · 2016-12-01 10:46 · Score: 0

Yes they are.
That's the entire *point* of our calendar system. There are two aspects it maintains:
**In October, the sun should lie in the constellation of Libra (repeat as appropriate for other constellations on the ecliptic).
**At noon, the sun is "reasonably close" to the zenith (or the correct term for the maximum elevation in the sky, I think the zenith is technically directly over the top of the observer's head).
Any failure to add leap days and leap seconds will result in long term violation of these two "truths" and the calendar system becomes meaningless.
If you want to revamp the calendar system, have at it, but you'd better fucking think it through before spouting BS about "why do we put up with this shit".
---
NotAPK (posting ANON to preserve thread moderation)
Re:Not new, just a holiday reminder PSA by lgw · 2016-12-01 11:06 · Score: 1

Any failure to add leap days and leap seconds will result in long term violation of these two "truths" and the calendar system becomes meaningless.
Leap days are important. We managed without leap seconds until quite recently, and we could keep on managing. There are already plenty of places where the sun isn't "reasonably close" to the zenith at noon, and we survive. Aside from DST, timezone gerrymandering has produced some timezones that stretch across quite a bit of longitude. Heck, even within a normal-sized timezone, you can be off by 30 minutes if you're near the edge. Compare that error to the 27 leap seconds added over the past 45 years.
"Sun overhead at noon" is a perfectly arbitrary convention. If 1000 years from now it's "Sun overhead at eleven", that will just the the way it's been your whole life - or, heck, by then who knows how many planets Mankind will have spread across, the whole thing will likely be a joke. I think leap seconds mostly appeal to the kind of pedantic nerd who likes to start all his sentences with "actually ..." - the more complicated the basic things in life are, the more smug he gets to feel.
If we had any sense we'd redefine the second or the meter to make the speed of light exactly 3x10^8 m/s anyhow.

--
Socialism: a lie told by totalitarians and believed by fools.
Re:Not new, just a holiday reminder PSA by NotAPK · 2016-12-01 11:40 · Score: 1

No.
"or, heck, by then who knows how many planets Mankind will have spread across, "
You're a space nutter. If you think we're going anywhere within the next few thousand years you are grossly mistaken. The physics doesn't allow it.
As for your arguments against leap seconds. I hear you, and I understand your argument. The point is: the correction can be applied on an arbitrary timescale. Do we apply nanoseconds every few weeks? Or minutes every 30-100 years? Or something in between? Unless there is some other compelling reason, the leap-second represents a fair compromise between the timing resolution required and the period of updates.
Re:Not new, just a holiday reminder PSA by lgw · 2016-12-01 12:07 · Score: 1

If you think we're going anywhere within the next few thousand years you are grossly mistaken. The physics doesn't allow it.
Mars and Venus are both easy, by the "centuries from now" standard. Neither will have a 24-hour day.

Do we apply nanoseconds every few weeks? Or minutes every 30-100 years? Or something in between?

I stand by "never" as the preferable choice. The timing solution is not "required", heck, it's barely even "useful".

--
Socialism: a lie told by totalitarians and believed by fools.

Google is so omnipresent it controls time now by Anonymous Coward · 2016-12-01 03:01 · Score: 0

Dumb I know, but it was difficult not to. I had a spare second to waste.

Re:Google is so omnipresent it controls time now by Anonymous Coward · 2016-12-01 03:18 · Score: 1

I had a spare second to waste.
But was it smeared or unsmeared? Enquiring minds want to know!

Sounds like a part of the Star Trek:DTI Manual by wiredog · 2016-12-01 03:03 · Score: 5, Funny

"don't mix smearing and non-smearing time servers"

--

Best Slashdot Co

Re:Sounds like a part of the Star Trek:DTI Manual by geekmux · 2016-12-01 05:26 · Score: 1

"don't mix smearing and non-smearing time servers"
And here I thought it sounded more like crossing the streams. Spengler told me to never cross the streams.
Re:Sounds like a part of the Star Trek:DTI Manual by Anonymous Coward · 2016-12-01 07:16 · Score: 1

"don't mix smearing and non-smearing time servers"
It's okay as long as you remember to calibrate inertial dampeners.
Re: Sounds like a part of the Star Trek:DTI Manual by Anonymous Coward · 2016-12-01 08:42 · Score: 0

Reminds me of Timecop. "Same matter cannot occupy the same space". When past and future selves interact they turn into a timeblob of death.
Re:Sounds like a part of the Star Trek:DTI Manual by countach · 2016-12-01 10:09 · Score: 1

Don't mix the time servers or cross the beams. It would be bad. Try to imagine all life as you know it stopping instantaneously and every molecule in your body exploding at the speed of light.Total protonic reversal! Important safety tip. Thanks, Google!

Some examples of smeared time by squiggleslash · 2016-12-01 03:04 · Score: 5, Funny

At 4.37 it'll report that 4.38 molests goats. 4.38 will retaliate by claiming 4.37 killed a man and lied about it. 4.39 will accuse 4.38 of secretly having two wives who know nothing about one another. 4.40 will claim 4.38 and 4.37 are having a secret affair and are making up allegations about one another to hide the fact. 4.41 will claim 4.40 is a multiple felon. 4.42 will accuse 4.41 of cheating on his taxes...

--
You are not alone. This is not normal. None of this is normal.

Re:Some examples of smeared time by Anonymous Coward · 2016-12-01 03:23 · Score: 0

and 7... 8 9
Re:Some examples of smeared time by Ashtead · 2016-12-01 04:05 · Score: 4, Funny

And meanwhile 4:20 enjoys a joint off to the side.

--
SIGBUS @ NO-07.308
Re:Some examples of smeared time by TheRaven64 · 2016-12-01 04:19 · Score: 2

Did that read like an extract from Exodus to anyone else?

--
I am TheRaven on Soylent News
Re:Some examples of smeared time by Anonymous Coward · 2016-12-01 05:46 · Score: 1

and 4:04 was not found for comment.
Re:Some examples of smeared time by Anonymous Coward · 2016-12-01 07:09 · Score: 0

And 4:61 was found breaking the law. AGAIN.
This is the 1th time this day!
Re:Some examples of smeared time by skegg · 2016-12-01 09:32 · Score: 1

Nice one: just logged-in to say that was brilliant!
Re:Some examples of smeared time by Obfuscant · 2016-12-01 09:58 · Score: 1

If you want information you should talk to 4:11.

Don't mix the servers? by Anonymous Coward · 2016-12-01 03:07 · Score: 1

Jesus Christ, this sounds like an April Fool's joke.

Re:What does Trump have to do with this? by Anonymous Coward · 2016-12-01 03:07 · Score: 0, Funny

Oh, and here I thought it was "Trump for cows, cows that Trump". MOOOOO!

Now go edit your luddite hosts file apps and get off my lawn.

Retarded by Anonymous Coward · 2016-12-01 03:07 · Score: 0

This is the dumbest technical solution I've read in years.

Re:Retarded by carlos92 · 2016-12-01 03:49 · Score: 1

Why? Where do you see an advantage in not smearing leap seconds?
Re:Retarded by beelsebob · 2016-12-01 05:17 · Score: 1

It's actually closer to the correct implementation - leap seconds are the technical solution to try and get us back closer to the correct time. Making seconds marginally longer is actually more accurate.
Re:Retarded by jellomizer · 2016-12-01 05:32 · Score: 1

If the system is time sensitive. Say like some sort of GPS system, where if the time is a little slower then your calculations may be off.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Re:Retarded by Anonymous Coward · 2016-12-01 05:39 · Score: 1

Some sort of GPS system should probably be using the time that the satellites are providing.
Re:Retarded by yet+another+SanTiago · 2016-12-01 05:49 · Score: 1

With 20 hour smearing you get that for ~10 hours (i.e. significant time interval) time on synchronized computers would be more than 1/2 sec (i.e. human-noticeable difference) from correct value. That is substandard quality for time synchronization.
Re:Retarded by Anonymous Coward · 2016-12-01 05:58 · Score: 0

Right up to the point when the leap second happens and your GPS crashes.
Re:Retarded by Anonymous Coward · 2016-12-01 07:19 · Score: 0

Some sort of GPS system should probably be using the time that the satellites are providing.
But if the GPS time is not the same as Google time.... hey wait, that's why when I use Waze to drive home I keep ending up in the ocean.....
Re:Retarded by sjames · 2016-12-01 07:24 · Score: 1

The defacto non-solution does much the same thing to the system clock after the leap second in order to correct for suddenly being 1 second fast but maintain monotonic time. That is, adjtime (or adjtimex) gets called to slew the clock.
In many cases, the defacto non-handling is the right thing to do. Although it compresses events very slightly, it maintains causality in the system logs and such.
Re:Retarded by Anonymous Coward · 2016-12-01 09:49 · Score: 0

That's why GPS doesn't have leap seconds at all, and anyone relying on NTP for GPS is asking for it.
Re:Retarded by fisted · 2016-12-03 00:40 · Score: 1

Except that a second is defined in terms of [what is emitted by] a phase transition of some particular element, or possibly in terms of the speed of light. Neither of which cares or has anything to do with Earth going around the Sun, and spinning around its own axis.
So "more accurate" is wrong. It will conflict with everything that does not both a) smear time and b) smear time in the exact same way google does.

--
CLI paste? paste.pr0.tips!
Re:Retarded by jellomizer · 2016-12-03 02:12 · Score: 1

The question was if there could be a problem with Smeared Time.
I have an answer. It probably isn't the best solution to the problem, but it is a problem that exists.

--
If something is so important that you feel the need to post it on the internet... It probably isn't that important.

Hey look the flow rate is a little high. by Anonymous Coward · 2016-12-01 03:14 · Score: 0

Let's just slow that down. Hope that wasn't important. What is 0.0014% between friends?

Re:Hey look the flow rate is a little high. by arth1 · 2016-12-01 03:34 · Score: 2

Let's just slow that down. Hope that wasn't important. What is 0.0014% between friends?
Friends that do low-latency high stake stock trading may have issues if some of competing parties run on a skewed clock (or syncs with something that syncs with something that runs on a skewed clock) and others don't. That affects not only the latency, which is important enough, but as the skew increases until the end when the leap seconds kicks in, and because the leap second is added at midnight UTC while bourses around the world are offset from that, it could mean that some might get a large part of a second more than others at cutoff time, which is an eternity in this context.
Re:Hey look the flow rate is a little high. by Anonymous Coward · 2016-12-01 04:00 · Score: 1

If your work depends so precisely on timing, then you should be handling your own timekeeping.
Re:Hey look the flow rate is a little high. by JaredOfEuropa · 2016-12-01 04:34 · Score: 2

I suspect very few here will any any sort of sympathy for people who do low latency stock trading. Some even suggested to add time skew or random jitter to stock tickets precisely to prevent this sort of trading.

--
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
Re:Hey look the flow rate is a little high. by arth1 · 2016-12-01 05:15 · Score: 2

If your work depends so precisely on timing, then you should be handling your own timekeeping.
No, the concern isn't whether your time is correct, but whether it is the same as the time others use.
That is not solved by adding an atomic clock. In fact, it might make it worse.
Re:Hey look the flow rate is a little high. by arth1 · 2016-12-01 05:24 · Score: 1

I suspect very few here will any any sort of sympathy for people who do low latency stock trading.
That's short-sighted thinking. Low latency traders exist, whether we like them or not[*], and it does not affect just the traders, but the stocks they trade, the companies, and other stock holders not involved in low latency trading. Their ability to do harm to others is affected when the playing field shifts, giving advantages to some. They're at war with each other, and the playing field being level helps maintain status quo, and prevent stocks from crashing or soaring when they shouldn't.
[*]: I too think they're scum. I'd like to see all stock trades have a delay of one business day.
Re:Hey look the flow rate is a little high. by MightyYar · 2016-12-01 05:42 · Score: 4, Insightful

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.
Re:Hey look the flow rate is a little high. by Anonymous Coward · 2016-12-01 06:01 · Score: 0

They never said "correct", just that you need to control your own time No one anywhere has the same time, but some groups may be closer in time than others. If you're in one of those groups, then you want to keep your time as close to the group. That is your problem and your responsibility. If everyone else votes with their feet to use "smeared time", then you can decide if you will follow or not.
Re:Hey look the flow rate is a little high. by sjames · 2016-12-01 06:05 · Score: 1

Handling your own timekeeping doesn't necessarily mean having your own atomic clock. In this context, it means deciding on who has the canonical clock and syncing with it.
Google is explicitly saying they are not serving UTC, so if your trading partners are on UTC, you're an idiot if you sync to Google.
Re:Hey look the flow rate is a little high. by BronsCon · 2016-12-01 06:18 · Score: 3, Insightful

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.
Re:Hey look the flow rate is a little high. by arth1 · 2016-12-01 06:27 · Score: 1

But that's the problem - you can decide who you sync with, but you cannot decide who others sync with.
A time discrepancy is a problem in either case.
The most obvious solution is that the bourses should provide time synchronization, and that everyone else sync to their time, right or wrong.
Re:Hey look the flow rate is a little high. by _merlin · 2016-12-01 07:22 · Score: 2

How will you decide on order priority within the one-second batches? Price/time priority? Favours people with fastest connection as they can quote beyond the price they would be filled at when the batch trades and pull their quotes at the last moment if the market moves against them. Price/volume priority? Favours the bigger players who are pushing bigger orders around as well as people with faster connections. That's just two simple, obvious disadvantages to running mini auctions like this. If there was a simple solution, it would've been done already.
Some exchanges do implement technical measures to try and reduce gaming. For example KRX enforces fill ratio - there's a minimum proportion of your orders that must actually trade or you'll be penalised. This means you can't sit around placing orders and cancelling them all day with no intention of executing. But on the other hand, it means you can't readily quote, displaying an order at the price you're prepared to trade given current market picture and moving it when the market moves. This makes it harder for an investor to know what price they can actually get executed at, and leads to a silly game of trying to hit attractive orders as quickly as possible. So it still makes life harder for actual investors and favours the guy with the lowest latency price feed.
The main reason for the latency wars is just because margins are so thin. In the past, spreads were tens of cents. A market maker (back then typically one of the big brokers or investment banks) made tens of cents against the theoretical fair price on every security traded. Lower latency allows quoting tighter spreads (you can move quotes quicker if the market moves against you), so the market makers are making far less money per trade - only a few cents per security minus exchange fees and government taxes on every trade. Because the profit per trade is really low, it's a cut-throat competition to get as many profitable trades as possible.
Re:Hey look the flow rate is a little high. by MightyYar · 2016-12-01 08:08 · Score: 1

How will you decide on order priority within the one-second batches?

I wouldn't do it - people who do this sort of thing for a living would. If I'm just spitballing and you won't make fun of my naivety I could try to come up with some solutions. I'm not sure why FIFO wouldn't work just fine - simply fill the buffer until the next transaction window fires. It's the same system that is in place now, with larger quantum steps.

--
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Re:Hey look the flow rate is a little high. by _merlin · 2016-12-01 08:41 · Score: 1

I actually do this for a living, and I'm telling you that 1-second intervals would make the market less stable and more prone to price fluctuations. This would make the effective transaction costs for investors higher and put more money into the pockets of market makers. But sure, if that's what you want to do, pressure your market regulators for a change like that. It's more money for me in the end.
Re:Hey look the flow rate is a little high. by MightyYar · 2016-12-01 09:49 · Score: 1

Before you go for my throat, I was simply proposing a way to put the kabash on low-latency stock trading. I don't actually have a strong aversion to it, and though I'm pretty ignorant about the whole thing tend to agree with you. But if stopping the low-latency guys is your goal, it's pretty straightforward.

--
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
Re:Hey look the flow rate is a little high. by F.Ultra · 2016-12-01 09:58 · Score: 1

No they don't. The clock is quite unimportant for the HFT crowd. All they care and look at are the incoming orders and changes in price, the importance of the clock is only important for later record keeping by firms allowing clients to trade via their accounts (aka stock brokers) since they have to prove to the authorities later that they gave their clients the best price available at the time from the various exchanges that they trade on but that is also not a problem since you then simply aggregate the log of each exchange as you see orders coming from them (it does not matter if the clocks on the exchanges differ since what is important is the order in which you received each message, i.e that is what defines when your system could see the best price).
Re:Hey look the flow rate is a little high. by F.Ultra · 2016-12-01 10:00 · Score: 1

Exactly this, some exchanges like the Canadian Alpha Exchange uses a random 1-3ms speed bump delay on each incoming and outgoing message. Other exchanges receive orders until a specific time at which point they arrange the orders based on price and not on time and matches which combinations of bids and asks that would create the fairest price and highest trade volume, aka continous auctions.
Re:Hey look the flow rate is a little high. by sjames · 2016-12-01 10:37 · Score: 1

Exactly. If you are part of a group making financial transactions, that group needs to decide on a canonical time source. And yes, it's relation to the rest of the world is irrelevant to the transactions.
In any event, all time sources are wrong to some degree. If you're using NTP over the internet, you will perhaps keep the error below a tenth of a second. A directly attached GPS clock will keep it closer but the error will remain non-zero.
Re:Hey look the flow rate is a little high. by Anonymous Coward · 2016-12-01 10:51 · Score: 0

How will you decide on order priority within the one-second batches?
Could you just have a random-number lottery? Every order has an equal probability of being processed? That seems fairest. The idea of batches is to not favour any particular player.
It's a pipe-dream though. There's no way the current investors would accept it, and they're the ones with the power/influence to make it (not) happen.
Re:Hey look the flow rate is a little high. by F.Ultra · 2016-12-02 10:23 · Score: 1

You don't consider the priority at all. What you do is that you calculate which price would yield the best volume and fairest price, i.e you calculate a equilibrium price. Most stock exchanges already does this during opening and closing (via the open and closing call) in order to precisely avoid price fluctuations when determining the opening and closing prices. Some exchanges like the Frankfurt Stock Exchange even run such auctions continuously during the trading day (Continuos Auctions) on some of it's markets. Another model which is done by Alternativa (http://alternativa.se/), although for highly illiquid shares, where traders enter orders for four days and on the fifth a fixing price is determined at which trades are calculated so there can be only one trading session per week (so it would of course not work for something as liquid as the Nasdaq or NYSE).

Re:What does Trump have to do with this? by Opportunist · 2016-12-01 03:15 · Score: 1

"Only Trump made that extra second for Americans possible!"

or

"A typical smear campaign by Trump supporters!"

Pick your side.

--
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.

Falsehoods Developers Believe About Time by Pseudonymous+Powers · 2016-12-01 03:17 · Score: 1

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.

I wonder why they're "smearing" the time over 20 hours rather than 24, which would seem the more obvious solution.

Re:Falsehoods Developers Believe About Time by heypete · 2016-12-01 03:31 · Score: 4, Informative

Because that's how they did it before and they consider it "safer" in the context of not making uneccessary changes this soon to the leap second. In the future they plan to do it 24 hours in advance:

Although we decided it would be safest for Google's infrastructure to handle the 2016 leap second using a 20-hour smear, the same way we handled the leap seconds in 2012 and 2015, this is not the only smear that works well. Many organizations use smeared clocks, and it would be helpful if the smears were the same. After all, the purpose of clocks is to read the same time in different places.
We would like to propose to the community, as the best practice for leap seconds in the future, a 24-hour linear smear from noon to noon UTC. We plan to use this smear starting from leap second #38, which is likely to be in 2018.
Source: https://developers.google.com/time/smear.
Re:Falsehoods Developers Believe About Time by __aaclcg7560 · 2016-12-01 03:38 · Score: 1

Using the number 10 probably made the calculations more easier to figure out on the back of a napkin. What's obvious is not always simpler.
Re:Falsehoods Developers Believe About Time by EvilSS · 2016-12-01 04:51 · Score: 2

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.
I wonder why they're "smearing" the time over 20 hours rather than 24, which would seem the more obvious solution.
Metric

--
I browse on +1 so AC's need not respond, I won't see it.

Re: What does Trump have to do with this? by NatasRevol · 2016-12-01 03:23 · Score: 0, Offtopic

But can I app a Trump, or can I only Trump an app?

Can you trump Trump's app?

--
There are two types of people in the world: Those who crave closure

Good job by Anonymous Coward · 2016-12-01 03:26 · Score: 0

Congratulations, you've made a relatively simple problem 100x more complex, and introduced competing, incompatible solutions.

Re:Good job by Immerman · 2016-12-01 04:48 · Score: 1

Really? You think getting every program on the planet that that interacts with Google's time servers to reliably handle a minute with 61 seconds without any ill effects is simple?
Meanwhile, very little software, even time-sensitive software, has has any concept of real time, only clock-time, so making the clock run very slightly slower accomplishes the same thing while making everything look like (very slightly faster) business as usual, with the only potential conflicts coming from slight ( 1 second) inconsistencies between different time servers. And I would venture a guess that very few applications rely on different time servers being perfectly synchronized to begin with.
And as they mention, Google is actually attempting to coordinate a smearing standard with other time-server operators as well.

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Re:Good job by AvitarX · 2016-12-01 07:45 · Score: 1

As I read it, the worse is 1/2 second (slowly fades to a half second behind, then leap second puts it a half second ahead and is slowly fades to match).
Since the Unix timestamp ignores leap seconds anyway, this seems like a very reasonable approach.

--
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
Re:Good job by Anonymous Coward · 2016-12-01 09:59 · Score: 0

Oh look, another naive junior programmer who thinks timekeeping is just a linear count of seconds and maybe daylight savings time.
Re:Good job by Immerman · 2016-12-01 15:25 · Score: 1

Good point, I stand corrected.

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Re:Good job by Anonymous Coward · 2016-12-03 00:49 · Score: 0

I'll just leave this here.

Re:What does Trump have to do with this? by __aaclcg7560 · 2016-12-01 03:28 · Score: 0

Trump voters like Samsung smart phones and Hillary voters like iPhones. One explodes on Twitter, the other is business as usual.

http://www.wsj.com/video/trump-voters-like-samsung-clinton-voters-like-apple/73985F23-0029-4B38-BC3A-EE6CEF33C69C.html

Smearing that number between 0 and 1... by __aaclcg7560 · 2016-12-01 03:34 · Score: 1

We used to call this fuzzy logic back in the 1980's.

https://en.wikipedia.org/wiki/Fuzzy_logic

Re: What does Trump have to do with this? by Anonymous Coward · 2016-12-01 03:36 · Score: 0

You are all Trumps. Trumps say moo. MOOOOOOOOO! MOOOOOOOOO! Mooooo Trumps MOOOOOOO! Mooo say the Trumps. YOU LUDDITE TRUMPS!!

I dunno. Saying that Trump moos like a cow seems anti-Trump...

Re: What does Trump have to do with this? by Anonymous Coward · 2016-12-01 03:37 · Score: 0

Modern app appers know that ONLY apps can app other apps! Only LUDDITES app Trumps!

Apps!

Well actually... by watermark · 2016-12-01 03:37 · Score: 4, Funny

*pushes glasses up* *straightens pocket protector*

Actually, they would need to run the clocks 0.0013889% slower. If ran the clocks 0.0014% percent slower, they would gain 1.008 seconds instead of just 1 second even.

Hire me Google. I'll save the internets for you.

Re:Well actually... by Anonymous Coward · 2016-12-01 04:56 · Score: 0

This is the post we've been looking for! A+++++++++++++++++++++
End dream sequence.
Re:Well actually... by The-Ixian · 2016-12-01 07:21 · Score: 1

This is the post we've been looking for! A+++++++++++++++++++++
End dream sequence.
Are you the Universal Migrator?

--
My eyes reflect the stars and a smile lights up my face.
Re:Well actually... by thegarbz · 2016-12-01 07:42 · Score: 1

And here I thought I was the only one who listens to that weird stuff.
Re:Well actually... by Anonymous Coward · 2016-12-01 07:45 · Score: 0

Thank you, Sheldon.
Re:Well actually... by Whip · 2016-12-01 12:24 · Score: 1

Nope! ...see you at ProgPowerUSA next year... ;)

Inaccurate time by Anonymous Coward · 2016-12-01 03:39 · Score: 0

Just to be clear, they will be providing *inaccurate* time for 20 hours.

Re:Inaccurate time by Immerman · 2016-12-01 04:57 · Score: 1

To be even more clear, every clock on the planet is constantly providing inaccurate time, since we've established a very precise standard unit of time (the second) that bears only an approximate relationship to the non-constant physical phenomena that originally defined it (1/86,400th of a mean solar day)

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.
Re:Inaccurate time by yet+another+SanTiago · 2016-12-01 05:58 · Score: 1

Historical definition of second is irrelevant. Current time standards (TAI, UTC) are defined in terms of the current definition of second. If a clock reports time sufficienty near to appropriate time standard, then it is by definition correct.
Re:Inaccurate time by Anonymous Coward · 2016-12-01 08:41 · Score: 0

To be even more clear, every clock on the planet is constantly providing inaccurate time, since we've established a very precise standard unit of time (the second) that bears only an approximate relationship to the non-constant physical phenomena that originally defined it (1/86,400th of a mean solar day)
And I put up a very large sail to slow the planet's rotation....
Re:Inaccurate time by Immerman · 2016-12-01 15:25 · Score: 1

Well, that is kind of the point of the leap seconds - to compensate for just such unpredictable changes in the Earth's rotation...

--
--- Most topics have many sides worth arguing, allow me to take one opposite you.

Tired of this shit. by LTIfox · 2016-12-01 03:41 · Score: 5, Interesting

Can we just move to TAI and convert to UTC only when interfacing the meatspace?

Re:Tired of this shit. by LTIfox · 2016-12-01 03:51 · Score: 3, Interesting

I mean, we have timezone stuff already - just bury those seconds in those tables. Run machine clock at TAI and calculate "local time" by adding, for example, 8hrs35seconds to whatever local timekeep says.
Re:Tired of this shit. by TheRaven64 · 2016-12-01 04:23 · Score: 3, Insightful

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
Re:Tired of this shit. by Xylantiel · 2016-12-01 05:37 · Score: 3, Insightful

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).
Re:Tired of this shit. by Anonymous Coward · 2016-12-01 06:24 · Score: 0

Me too. That's why I use D4.
http://www.thinkman.com/dimens...
Re:Tired of this shit. by Anonymous Coward · 2016-12-01 07:43 · Score: 0

wreaks? Yeah, that sounds like a military approach.
Re:Tired of this shit. by Hognoxious · 2016-12-01 10:18 · Score: 1

Let enough accumulate and they'll be useful to everybody.
If they're really ruining your omelettes, there's two pseudozones without them - TAI and GPS.

--
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Re:Tired of this shit. by tricorn · 2016-12-01 10:18 · Score: 3, Insightful

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.
Re:Tired of this shit. by jaa101 · 2016-12-01 10:26 · Score: 1

You're forgetting navigation. 4 seconds to the nautical mile. Don't let UTC drift more than a second.
Re:Tired of this shit. by Anonymous Coward · 2016-12-01 14:24 · Score: 0

64 bit signed seconds? Why not microseconds?
Re:Tired of this shit. by tricorn · 2016-12-01 20:40 · Score: 2

You really want a higher resolution than microseconds. The clock_gettime() system call returns the number of seconds and nanoseconds in two separate values. If you return the number of nanoseconds in a 64-bit signed value, you have a range of only +/- 292 years, which is limiting if you want to use it for historical dates or longer term future dates.
With a 64-bit signed seconds value you can go +/- 292 billion years. With a 64-bit value for the fractional part, you could easily increase the resolution to attoseconds (1E-18, 60 bits). Both those limits are not very constraining.
Re:Tired of this shit. by Mal-2 · 2016-12-01 22:48 · Score: 1

With a 64-bit signed seconds value you can go +/- 292 billion years. With a 64-bit value for the fractional part, you could easily increase the resolution to attoseconds (1E-18, 60 bits). Both those limits are not very constraining.
Sure, you say that now, but when it comes time to fix the Y2.92×10^6K bug, are you willing to pay for it?

--
How is the Riemann zeta function like Trump rallies? Both have an endless number of trivial zeros.
Re:Tired of this shit. by fisted · 2016-12-03 00:57 · Score: 1

Your arrogance wreaks of someone who has never served in the military
You mean it wreaks(sic) of a sane person?

particularly in a combat role.
How is that anything to be proud of. If you did that, it only shows that you're dumb, expendable and probably wouldn't have contributed to society in any constructive way anyway.
That said, how does any of this matter to TAI vs UTC, my dear mil-grade potato?

--
CLI paste? paste.pr0.tips!

What, is Google new or something? by Excelcia · 2016-12-01 03:42 · Score: 1

NTP shouldn't have to smear it. All that will happen is that one second your computer will think it's on time, and a couple seconds later your computer will think that it's a second behind and correct itself against the NTP server. Computer clocks are inaccurate enough that it's expected they will drift by a few seconds in a day anyway and NTP corrects that quite handily already.

Instead of making NTP servers smear a second over twenty hours, here's an idea, how about just implementing support for it at the OS level? It's not like this phenomena is new. It's been around since 1972, longer than many countries have been implementing daylight savings, yet that little gem happens twice a year without a hitch. Despite this, proposals for abolishing leap seconds continue to abound, and claims that the next one will make the sky fall continue to waste people's attention. There have been 27 leap seconds since 1972, and not a single one of them has broken the world yet.

I suspect Google spent more time adjusting their NTP servers to wingle around it than it would have taken for them to, say, update Android to support it.

Re:What, is Google new or something? by Anonymous Coward · 2016-12-01 04:01 · Score: 0

> how about just implementing support for it at the OS level?
If you make time differences (e.g. seconds since the epoch or seconds between t1 and t2) include leap seconds, then you can no longer convert between seconds and other units (minutes, hours, days, etc) with formulae, you need a look-up table.
And either you make every computer in the world do it the same way, or you have to be able to answer the "is that with or without leap seconds?" question.
If you need to measure rate of change, use monotonic time. For accurate absolute time, use TAI. For everything else, POSIX time (i.e. 86400ths of a day, colloquially termed "seconds") is the right solution.
Re:What, is Google new or something? by green1 · 2016-12-01 04:02 · Score: 2

Android, or even your desktop OS aren't the point. You are correct that consumer level devices have no problem "fixing" their clock by a second when they discover it. The problem is when you have tons and tons of real time transactions that have to be kept in a very precise order. How do you easily and reliably determine which event happened first if the numerical timestamp isn't sequential? Smearing the second ensures that timestamps, of any precision, remain sequential. This can be crucial for some of these large real-time organizations.
The only other somewhat practical solution is to implement it like we do leap years, however as leap seconds are not as predictable, you run the risk of whether every system has the correct version of the database with the leap-seconds enumerated, and add extra computing resources on every translation to human readable formats. Google correctly points out that no current consumer OS currently has this capability, and you'll find that data-centre OSes are generally the same. While Google can control one or two of those, they can't guarantee that every device they send something to will also support it.
The leap second smear is a very elegant solution to a real, and somewhat complex, problem.
Re:What, is Google new or something? by Anonymous Coward · 2016-12-01 04:04 · Score: 0

phenomenon
Re:What, is Google new or something? by Anonymous Coward · 2016-12-01 04:06 · Score: 0

Daylight savings time works "without a hitch"? Guess you're lucky enough to work where nobody ever schedules something during the hour that gets skipped or repeated. Or they are smart enough to write things so they check if they've been run already that day or not. Apple certainly had very public daylight savings time bugs in ios in 2010, 2013, and 2014.
Leap second bugs are going to be much harder to notice, but that doesn't mean they couldn't occasionally be critical. Building support for them into the OS would be useful, but difficult, as (per Wikipedia) when to insert the leap second is usually decided about six months in advance.
Re:What, is Google new or something? by Anonymous Coward · 2016-12-01 04:38 · Score: 0

No one who knows anything about NTP will ever claim that several servers in the same physical room are within the time keeping tolerances you describe above. Much less the world.
Re:What, is Google new or something? by ZorinLynx · 2016-12-01 04:54 · Score: 2

>All that will happen is that one second your computer will think it's on time, and a couple seconds later your computer will think that it's a second behind and correct itself against the NTP server.
The problem here is that not all systems adjust at the same rate. So once all the systems are a second off, they will all be slightly out of sync with each other as they skew their clocks until they're all correct again.
For us, clocks being under a second out of sync is not a big deal. But for software that has to be well synchronized between hosts, it's a huge deal. So it's better to do it Google's way to keep their infrastructure working reliably.
Re:What, is Google new or something? by Anonymous Coward · 2016-12-01 05:09 · Score: 0

Why not simply add 1 hour (60 minutes) after the 3600th leap second event which if coordinated correctly could occur at the same time as the one-hour fallback or one-hour advance during that year? In the meantime, time matches on and nobody is out of synchronisation despite the slowly increasing interval between 0 seconds and 3600 seconds.over the span of many years.
Re:What, is Google new or something? by Anonymous Coward · 2016-12-01 06:13 · Score: 0

NTP is not an OS. Not all OSs can support your proposed change. Some implementations of OSs are in embedded devices that cannot be changed. The ONLY universally compatible way to handle this situation is to smear the time.
Re:What, is Google new or something? by Anonymous Coward · 2016-12-01 06:20 · Score: 0

My custom build firewall with a $60 consumer-grade motherboard is within 0.2ms of a group of NTP servers 101 hops and 1,100 miles away, and has less than 0.001ms of drift between the 5min NTP syncs. When my firewall is running max throughput, causing the CPU usage to wildly swing, I can get up-to 2ms off between syncs. Most of that is because of many load/idle transitions and changing temperatures. What kind of absolutely shitty hardware are you using that can't keep time within 1 second?
Re:What, is Google new or something? by Anonymous Coward · 2016-12-01 07:15 · Score: 0

The issue you point out isn't a real one.
Concurrency and transaction based systems don't use the notion of time as you think they do. "Happens before" is a rigorously defined relationship between two events and is what is used with transactions. Nothing in concurrency demands that timestamps even exist. Locking, lock-free, and wait-free concurrency do not require timestamps. When database transactions are logged, they do not require timestamps - the timestamps are usually for the benefit of humans when reading logs or when performing analytics/forensics on an event that happened.
I'm willing to bet that 99.99999% of all software on the planet doesn't need to be concerned about leap seconds, especially if they use a NTP server.
As the other AC mentions, you cannot prove any two machines have the same time. Doing so is an effort in futility - if you think you have a method of doing so, you should write up a dissertation, get your PhD, and silently wait for your Nobel prize.
Re:What, is Google new or something? by SuiteSisterMary · 2016-12-01 07:47 · Score: 1

The problem is when you have tons and tons of real time transactions that have to be kept in a very precise order. How do you easily and reliably determine which event happened first if the numerical timestamp isn't sequential?
You use a unique, sequential value independent from timestamp, I'd hope.

--
Vintage computer games and RPG books available. Email me if you're interested.
Re:What, is Google new or something? by green1 · 2016-12-01 08:19 · Score: 1

If the servers can't sync within a full second, we should give up on NTP entirely.
Many things require far more precise timing than that.
Re:What, is Google new or something? by green1 · 2016-12-01 08:21 · Score: 1

Hey, if you know how to run large internet connected systems better than Google, maybe you should step up and compete. As obviously you think they're clueless about such things and you know better.
I look forward to all your new systems that make Google obsolete.
Re:What, is Google new or something? by sjames · 2016-12-01 08:34 · Score: 1

That's actually fairly close to the do-nothing approach used by default. When you run ntpd, it periodically checks th time and used adjtime, adjtimex or some equivalent to slew the clock as needed to get back in step. It does nothing special with the leap second flag since the system clock has no way to handle it anyway. After the leap second, the NTP client notices that the system clock is 1 second fast and so slews it back one second.
The clock slew is done by slowing the clock just a bit so it continues to provide monotonic time (it will never provide timestamps out of order) and comes into sync over the next few minutes.
Re:What, is Google new or something? by Anonymous Coward · 2016-12-01 19:11 · Score: 0

In order to get round a time jump, we are going to break any notion of accuracy for 20 hours.

I'm impressed by Anonymous Coward · 2016-12-01 03:49 · Score: 0

It sounds like a good, practical solution to the problem.
It appears that Google is big enough so it's useful to everybody for them to have their own time zone.
Technically they are, but non-technically, they are probably not big enough to change legal time.

Hopefully, most folks that care use GPS for time, but maybe not.
It should be interesting to see what unintended consequences occur.
Things that come to mind are:
End of year stock trades might happen in the wrong year.
HFT might do something unintended that makes the news.
Hopefully nothing that gets anybody hurt will happen.

They might consider a more visible warning.
It will be interesting to see what shows up on the splash picture at www.google.com?

One OS has been doing this for years by Anonymous Coward · 2016-12-01 03:49 · Score: 0

IBM's z/OS has been adjusting mainframe clocks for years by "smearing", that is making microseconds adjustments over a period of time to correct clocks and account for leap seconds. But then I guess it is not a commonly used OS since it is only used by millions (unknowingly).

Re:One OS has been doing this for years by OrangeTide · 2016-12-01 07:45 · Score: 1

That's not POSIX compatible.

--
“Common sense is not so common.” — Voltaire

O cursÃd spite by Bruce+Perens · 2016-12-01 03:51 · Score: 1

I can't ever see a story like this without thinking "O cursÃd spite".

--
Bruce Perens.

Re:O cursÃd spite by Bruce+Perens · 2016-12-01 03:52 · Score: 4, Funny

Geez, foiled by Slashdot's non-UTF8-ness again.

--
Bruce Perens.
Re:O cursÃd spite by Anonymous Coward · 2016-12-01 09:35 · Score: 0

Slashdot is helpfully smearing out your accented characters across a span of Unicode, so your OS has fewer problems with leap code points.

Epoch time calculations by FeelGood314 · 2016-12-01 04:03 · Score: 1

Unix time - (also known as POSIX time or Epoch time) is a system for describing instants in time, defined as the number of seconds that have elapsed since 00:00:00 Coordinated Universal Time (UTC), Thursday, 1 January 1970, [note 1] not counting leap seconds.

This is fine for many systems but what about the systems that do count leap seconds. In January they will be 1 second ahead of POSIX time. I'm thinking of industrial equipment and electrical infrastructure. I'm also wondering about how log files will be matched up when different systems are assumed to be synced to under 1 second.

Oh wait, we will just see what breaks and kludge it in January.

Re:Epoch time calculations by caseih · 2016-12-01 04:33 · Score: 1

Somehow I doubt industrial equipment is tied into Google's NTP servers. But Google began doing this with their NTP servers back in 2011, and as far as unix servers go, there have been no issues with previous "smearing" so I don't expect any issues with this next leap second either.
Re:Epoch time calculations by Anonymous Coward · 2016-12-01 04:47 · Score: 1

Your servers don't drive telescopes, do they?
Really I'm glad I have my own NTP servers. There are still bugs, but at least we won't have to stop the telescope for 20 hours. Only stop a bit before the leap second and reboot a little later.
Re:Epoch time calculations by Anonymous Coward · 2016-12-01 04:52 · Score: 0

Normally a smearing NTP server does not set the leap second flag. A client that would be capable to use it thus doesn't. Otherwise a capable client would receive the smeared time AND at the same time apply whatever leap second correct it has (a 61th second, another type of smearing, a jump in time, using some OS api for reporting the leap second, ...)
Re:Epoch time calculations by Anonymous Coward · 2016-12-01 05:35 · Score: 0

No, we won't. leap seconds are nothing new, and monotonic time never needs to be in sync to anything else other than frequency (and often, phase).
Everything else gets corrected during shutdown maintenance anyway.
Re:Epoch time calculations by caseih · 2016-12-01 05:56 · Score: 1

Right this is about Google. Not my servers, or your servers. I suppose someone could unwittingly be using a Google NTP server unawares.
Re:Epoch time calculations by Anonymous Coward · 2016-12-01 07:23 · Score: 0

This is a non-issue. There aren't many systems that require precise time keeping in the real world. The systems that do require precise time keeping only require it within a certain bubble. Eg. A missile being armed on a fighter jet needs a very precise time - but it only has to be precise relative to the jet, and the jet only needs to be precise relative to the GPS signals it receives for proper targeting. Whether the Amazon cloud is within 1 second is irrelevant.
Log files are only of interest to humans in posthumous analysis of an event. The timestamps will be sequential as an artifact of sequentially writing to the log file. Comparing two log files from two different computers, and assuming the times are the same would be a hugely stupid thing to do. For analyzing communications between machines, you would use the happens-before relationship. Ie. One computer logs that it wrote a message out at 13:01. Another computer logs that it received a message at 5:37. If you assume the receive happened before the send, just because the timestamp is smaller - then you're already a fuckup. The receive didn't happen before the send, regardless of what the timestamps say. The same is true even when the timestamps are very close. Sending at 00:00:05 and receiving at 00:00:04999997 still does not imply the receive happened before the send. You would naturally conclude that the send happened before the receive, and that the two computers were not synchronized.
If the world's software required such tight tolerances on something as fickle as system time, we'd be hugely fucked. Every single day. Not just on leap second days.

Great... by Anonymous Coward · 2016-12-01 04:06 · Score: 0

Now in addition to the horribly over complex rules for timezones, daylight savings times, leap years and leap seconds there is a new rule which only applied to sources originating from a Google NTP server, cannot be adjusted for with arithmetic alone, and cannot even be assigned to a given timestamp because the origin of the time is impossible to determine in most cases. Good job, the only think that could be more innovating and productive would be if we nuked Google.

It's not that easy by Anonymous Coward · 2016-12-01 04:10 · Score: 1

From the blog:

Leap seconds compensate for small and unpredictable changes in the Earth's rotation, as determined by the International Earth Rotation and Reference Systems Service (IERS).

That is the problem; it's not well determined in advance, so simply distributing static tables of data is just not going to work all the time. Moreover, those tables are highly sensitive to political nonsense in any given locale. Thus, the Google folks are basically saying "All right. We declare ourselves to be the Great Overseers of time; at any given moment, just set your clocks to what we tell you!"

Re:It's not that easy by TheRaven64 · 2016-12-01 04:27 · Score: 2
Time zones compensate for the problem that, in different places in the world, the sun is not at its highest point at the same time. They provide a quantised approximation of a solution so that the sun is at approximately its highest point at noon. Time zones are sufficient wide that the error from being in a different place within a time zone is significantly larger than the error from the small changes in rotation that leap seconds compensate for. If we didn't have leap seconds, this would remain true for about the next thousand years. I propose that in 1,000 years one of the following will hold:
- The position of the sun will not matter too much to the majority of the human race.
- Humans will be extinct.
- Civilisation will have collapsed to the point where a universal time standard is irrelevant.
It's really hard to come up with a scenario in which the problem that leap seconds solve actually exists.
--
I am TheRaven on Soylent News
Re:It's not that easy by Xylantiel · 2016-12-01 05:50 · Score: 4, Insightful

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.
Re:It's not that easy by Anonymous Coward · 2016-12-01 08:51 · Score: 0

Time zones compensate for the problem that, in different places in the world, the sun is not at its highest point at the same time. They provide a quantised approximation of a solution so that the sun is at approximately its highest point at noon.
And that's another reason the current time zone system is bad.
We should subdivide each of the 24 time zones into 3,600 units, and then we'll be accurate to the second about the highest point of the sun being at noon.
Of course, at the poles, this becomes REALLY fun.
Re:It's not that easy by Anonymous Coward · 2016-12-01 23:40 · Score: 0

To determine can also mean to ascertain, figure out by measurement, so there is no "subtle difference".

Re:What does Trump have to do with this? by TheRaven64 · 2016-12-01 04:15 · Score: 0

Please can you explain the connection between Trump, cows, apps, and luddites?

--
I am TheRaven on Soylent News

Interestingly enough... by Anonymous Coward · 2016-12-01 04:18 · Score: 0

looks like the Google Public NTP servers are stratum 2.

What's their reference clock?

address ref clock st when poll reach delay offset disp
*~216.239.35.0 71.79.79.71 2 46 64 1 19.127 -2.123 0.122

$ host 71.79.79.71
71.79.79.71.in-addr.arpa domain name pointer cpe-71-79-79-71.columbus.res.rr.com.

Either Google is using a roadrunner home router as their reference clock, or someone forgot to update reverse DNS ;)

Smeared Seconds by wasteoid · 2016-12-01 04:36 · Score: 2

Smeared seconds come after sloppy seconds.

Re:Smeared Seconds by Anonymous Coward · 2016-12-01 06:51 · Score: 0

sloppy seconds, you say?
Re:Smeared Seconds by RockDoctor · 2016-12-04 05:40 · Score: 1

No, smeared seconds is the anal equivalent of sloppy seconds. Great if you like the extra lubrication.

--
Birds are not dinosaur descendants;birds are dinosaurs, for all useful meanings of "birds", "are" and "dinosaurs"

GPS or NIST by Anonymous Coward · 2016-12-01 04:57 · Score: 0

Why would I even want to use Google NTP servers when I could use NIST directly, or (to be more 'polite' to the NIST) use a Stratum-2 server from the list instead? Or, in my particular case, use the GPS receiver connected to my desktop machine for time sync? These are solutions that everyone can use.

Re:GPS or NIST by ledow · 2016-12-01 05:09 · Score: 1

NTP Pool is there for a reason.
Re:GPS or NIST by mbone · 2016-12-01 05:35 · Score: 1

Or you could use the USNO, the other official time reference for the United States.
Re:GPS or NIST by Anonymous Coward · 2016-12-01 05:57 · Score: 0

I like using a GPS receiver connected via a USB port, I can get atomic clock accuracy without any Internet connection, just the basic three satellite position fix. As a fallback I have WWVB clocks in my house. Really do need to retrofit one of those with a low PPM TCXO, though, so even without a recent time-sync it'll stay accurate for as long as the batteries hold up.
Re:GPS or NIST by Anonymous Coward · 2016-12-01 06:28 · Score: 0

NTP pool is horribly inaccurate. I used NTP pool for a few months, and the jitter and offset where always in the hundreds to thousands of milliseconds. I eventually googled a list of public NTP servers from some popular datacenters and now jitter and offset are less than 1ms, sometimes less than 0.1ms, even with a 100ms+ delay. There are some utterly horrible NTP servers in the pool.
Re:GPS or NIST by Anonymous Coward · 2016-12-01 06:48 · Score: 0

The USB protocol sends data in frames. USB1.1 uses 1ms frames, USB2.0 has a slot time of 125us. This adds jitter/phase noise. While your GPS may be very accurate, the time passed through USB is far from atomic clock level (on the short term at least, long term accuracy is like having your own primary standard). Probably doesn't matter for 'normal' clock usage, but I have seen scientific experiments doing just this going totally wrong.
Re:GPS or NIST by ledow · 2016-12-01 08:00 · Score: 1

If you're that worried, change your accepted settings.
But you're talking crap, as my NTP pool server gets PUSHED OFF the pool if it drifts anywhere near that far, or goes offline for even a short time.
Currently my jitters for uk.pool.ntp.org are:
0.071
0.079
0.050
0.190
Those numbers are IN MILLISECONDS. 0.05 of a millisecond.
And 0.478 on a stratum 1, famous, advertised, academic, public NTP server not in the pool.
Re:GPS or NIST by Rick+Schumann · 2016-12-01 09:25 · Score: 2

FFS I'm not doing anything requiring microsecond accuracy if it's within one second or less then it's fine, and unless you're running some sort of mission-critical operation that requires precise alignment to the atomic clock for some reason, you should probably just take your meds and calm the hell down about it.

The 7th voyage by k2r · 2016-12-01 05:05 · Score: 2

by Stanislaw Lem comes to my mind reading this.
"Well, the Monday me on Monday night became, Tuesday morning, the Tuesday me, and so on."

http://webcache.googleusercont...

Who you gonna call? by Anonymous Coward · 2016-12-01 05:17 · Score: 0

I've been smeared/slimed.

Leap Seconds by mbone · 2016-12-01 05:28 · Score: 2

A smeared second is stupid IMHO. People have had since 1973 to put leap seconds into their software. However, this is how NTP does it, so many computer clocks will have a smeared second even if they don't use Google.

UTC with leap seconds was set up to support celestial navigation. You can still take out your sextant and determine your position to a km or so using standard clock time. There is still a feeling that that is a useful attribute.

My personal feeling is that the Internet should just adopt TAI, but I have never gotten anywhere with that proposal.

Instead, this will go on until some plane crashes or rocket explodes or there is a massive exploit* due to a leap second being incorrectly handled, and then this will be fixed.

* There are some security protocols that make implicit assumptions about the time being roughly coordinated. On leap second day, those assumptions may be false,

Re:Leap Seconds by paraax · 2016-12-01 06:00 · Score: 2

Are you really claiming that "roughly coordinated" is at much less than 1 second resolution? If I understand correctly the maximum discrepancy would be half a second to occur at the actual point that the leap second is applied plus any normal deviation of the time systems. For most applications this is acceptable. Anything that is failing to fly or exploding due to this level of difference in time has bigger problems than the time servers being slightly off and is an accident waiting to happen. It would seem that such a sensitive application should be able to determine and adjust to a skewed time from an external source regardless of the reason.
Further the bugs introduced in the timing logic of numerous applications that don't care so much about timing, just that their clock agrees with the world, makes this the right answer for most applications. For what its worth it sounds like the right answer is to have smeared and non-smeared servers, with the smear period using the same period for the smeared servers. If you need precise time make sure your system can handle a 61 second minute and use the special case non-smeared servers.

You take your knife... by Anonymous Coward · 2016-12-01 05:43 · Score: 0

... and you smear. Men smear.

FUCK 2016 by Thud457 · 2016-12-01 05:59 · Score: 1

Jesus H Christ on a flaming pogo stick!
Just when we were starting to get to the last month of this AIDS-filled dumpster fire of a year, the go and add another goddamned SECOND to it.
I usually don't say things like this, but in this case, FUCK YOU, SCIENCE!

You know what's going to happen, they're going to start dropping Dick Clarke's frozen head in Times Square, and it's never going to reach the bottom. It will be the end of time and it will always be 2016, FOREVER.

--

the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff

Re:What does Trump have to do with this? by Anonymous Coward · 2016-12-01 06:06 · Score: 0

No, it's "News on Trump, Apps that Moo" with a subtitle of "Hot Grits and Frosty Piss in Your Hosts File. Android MacBook Pro Windows 10 iPhone Galaxy Note 7s Pixel."

good news everybody! by Thud457 · 2016-12-01 06:09 · Score: 1

I don't see why this should be a problem. NASA will fix this at the NASA/USGS Rotational Tuning Facility #9?

--

the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff

IETF BCP: no public smearing servers by Anonymous Coward · 2016-12-01 06:27 · Score: 0

Google has been smearing leap seconds over NTP since 2011. This is a public reminder that Google NTP will be serving smear seconds because there is one coming.

Best current practice (BCP):

Leap Smearing must not be used for public-facing NTP servers, as they will disagree with non-smearing servers (as well as UTC) during the leap smear interval.

* https://tools.ietf.org/html/draft-ietf-ntp-bcp-02#section-4.6.1

Re:IETF BCP: no public smearing servers by DavidRawling · 2016-12-01 09:13 · Score: 1

It's Google doing this. You just have do it Google's way because someone at Google arbitrarily decided it was the best thing to do for Google, regardless of existing standards, other environments or systems, or indeed the rest of the world breaking as a result.
Look at Gmail's implementation of addressing. Dots in the user portion of the address were significant in 1982 (RFC 822 / STD 11), but not for Google, who cannot differentiate Bob.Dole@ from BobDole@. Still. In twenty-freaking-sixteen.

"make" at 23:59:59.xxx dec 31 should work but... by ext42fs · 2016-12-01 06:31 · Score: 1

... it is not the best solution. A leap second table to make it a time representation issue would probably be better.

Segal's Law by Anonymous Coward · 2016-12-01 06:32 · Score: 1

Seems obligatory: "A man with a watch knows what time it is. A man with two watches is never sure."

O curséd spite! by Anonymous Coward · 2016-12-01 07:01 · Score: 0

O curséd spite!

O cursèd spite! by Anonymous Coward · 2016-12-01 07:06 · Score: 0

O cursèd spite!

wrong accent ò.ó ! by Anonymous Coward · 2016-12-01 07:11 · Score: 0

wrong accent ò_ó !

Publicing false time is ok? by Anonymous Coward · 2016-12-01 07:26 · Score: 0

So for 20 hours Google is publicing false time through NTP?

Re:What does Trump have to do with this? by nevermore94 · 2016-12-01 07:39 · Score: 1

Interesting. I hate them both and use a Moto Droid.

--
Nevermore.

Reject leap seconds by Anonymous Coward · 2016-12-01 07:40 · Score: 0

Which NTP servers should I use in order to reject leap seconds? Basically I'd like to stop using UTC (Coordinated Universal Time, which is ironically only applicable to Earth and not the entire Universe) and switch to TAI (International Atomic Time).

Re:What does Trump have to do with this? by Cro+Magnon · 2016-12-01 09:29 · Score: 1

I don't know about apps or luddites. I do know that Trump and cows generate methane.

--
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.

Majority rules by WaffleMonster · 2016-12-01 10:07 · Score: 1

If I were someone who actually cared about seconds and depended on high resolution timekeeping this would undoubtedly strike me as a really shit-headed idea.

Re: What does Trump have to do with this? by Anonymous Coward · 2016-12-01 13:57 · Score: 0

I'm going to use this, but add "with incrementally worse design" to the Hillary part.

Can I have a SMEAR YEAR, not a LEAP year by Anonymous Coward · 2016-12-01 13:58 · Score: 0

But don't quote me on that. If it's not the 31st of December.

"Smeared"? by thisisauniqueid · 2016-12-01 16:05 · Score: 1

Couldn't they have used a nicer word than "smeared", like maybe "interpolated"? (See also other aversion-causing words: "moist", "crevice", "phlegm", "penetration", etc.)

Caveat sysadmins by woboyle · 2016-12-01 16:43 · Score: 1

Given the behavior of the "smearing", they are NOT NTP servers you want to use with hard real time systems, especially if 1 second will prang your gear.

--
Sometimes, real fast is almost as good as real-time.

Slashdot Mirror

Google's New Public NTP Servers Provide Smeared Time (googleblog.com)

179 comments