Comment by natch | Hacker News Reader

Comment by natch | Hacker News Reader

I'm really doubting myself over this question, because who am I to think I might have found a mistake in Amazon's chart, but aren't these two comments in the table reversed?

1. "Each second is 1/86400 longer and AWS clocks fall behind UTC. The gap gradually increases to up to 1/2 second."

If the seconds are longer, wouldn't the AWS clocks be creeping ahead, not falling behind? Bear in mind the leap second hasn't been added to UTC yet at this point in the table.

2. "AWS clocks gain 1/2 second ahead of UTC."

They do? But an entire leap second was just added to UTC. Aren't the AWS clocks 1/2 second BEHIND at this point?

Note the time of the AWS smearing of this 1 second straddles the UTC injection with 12 hours on each side.

And then:

"AWS clocks keep falling behind and the gap with UTC shrinks gradually."

Shouldn't it be "AWS clocks keep catching up and the gap with UTC shrinks gradually"?

Not sure how I can be reading this so backwards, but if it's me who is wrong here, I'd love to hear why. In any case it shows how time is easy to get wrong (whether it's me who is wrong, or hah, doubtful, AWS).

What am I missing here?

Edit: duh yeah I get it now. Amazon is right, of course. Obviously I'm a n00b when it comes to dealing with leap seconds. I was thinking the leap second sets time ahead, but it doesn't; it effectively does the opposite. Leaving this message in place as an example of how thinking about time and calendar-related programming is easy to mess up.

I really do find thinking about time to be fiendish as well.

Here's some examples I thought of that may help clarify:

1. "Each second is 1/86400 longer and AWS clocks fall behind UTC. The gap gradually increases to up to 1/2 second."

- AWK clocks do indeed fall-behind when their "seconds" tick longer. Because their seconds tick longer, over a fixed period of time, AWS will count less ticks than UTC. (Think of it this way: A mile is longer than a kilometer. After you have traveled 800 kilometers, you've only traveled ~500 miles.)

2. "AWS clocks gain 1/2 second ahead of UTC." - Before the addition of the leap second, AWS clocks are behind by 1/2 second as per (1). The addition of a leap second to UTC is another second that the UTC clock must tick - the AWS clocks don't have to tick this amount - so the AWS clocks are now ahead by 1/2 second.

Basically, this is what AWS is doing, using our distance analogy again:

1. Normally, we have to cover 1000 km every day. This includes a Civil group of travelers and an AWS group of travelers.

2. Today, we decide we're going to cover 1001 km. Everyone in Civil decides this is OK to count to 1001 instead of 1000, just for today. But the AWS group only wants to count to 1000 because counting to 1001 is a Very Bad Thing. However, the AWS group still has to cover 1001 km.

3. The AWS group comes up with the ingenious idea of just making each "kilometer" 1.001 real-world kilometers, just for today. Thus, they will only count to 1000, but each time travel 1.001 km. The end result is the same - they will have covered 1001 km.

Think of it this way. Over the next time interval, the true UTC click ticks 10 times. Then the time becomes time+10. If the AWS clock has longer seconds and only ticks 9 times, then the time is only time+9 on their clocks. Therefore, the time at AWS is falling behind UTC, since UTC is incrementing faster.

  Leaving this message in place as an example of how  
  thinking about time and calendar-related programming is 
  easy to mess up.

Indeed, time and calendar related programming is quite tricky, even specifying what the behavior should be can be tricky and very non-intuitive.

Dealing with time zone issues in code has driven me batty more than a few times.

Reply on news.ycombinator.com