“Living Without Atomic Clocks” is an interesting article that covers some design bits of distributed systems and CockroachDB (what a name!), especially those related to time precision. This part in particular is the one I’m sure I’ll came back to at some point:
How does TrueTime provide linearizability?
OK, back to Spanner and TrueTime. It’s important to keep in mind that TrueTime does not guarantee perfectly synchronized clocks. Rather, TrueTime gives an upper bound for clock offsets between nodes in a cluster. Synchronization hardware helps minimize the upper bound. In Spanner’s case, Google mentions an upper bound of 7ms. That’s pretty tight; by contrast, using NTP for clock synchronization is likely to give somewhere between 100ms and 250ms.
So how does Spanner use TrueTime to provide linearizability given that there are still inaccuracies between clocks? It’s actually surprisingly simple. It waits. Before a node is allowed to report that a transaction has committed, it must wait 7ms. Because all clocks in the system are within 7ms of each other, waiting 7ms means that no subsequent transaction may commit at an earlier timestamp, even if the earlier transaction was committed on a node with a clock which was fast by the maximum 7ms. Pretty clever.
I’ve seen this chart before, but completely forgot where it was from. Tried to find it a couple of times in a hurry of a conversation, but couldn’t. Thanks to this SysAdvent blog post, I now have it permanently engraved into the archives of my blog.
xkcd figured out how long can you work on making a routine task more efficient before you’re spending more time than you save. The crossing of how much time you shave off and how often you do the task gets progressively less obvious when move from the top left corner of this char to the bottom right corner.
AWS Official Blog covers the upcoming leap second shenanigans in “Look Before You Leap – The Coming Leap Second and AWS“:
The International Earth Rotation and Reference Systems (IERS) recently announced that an extra second will be injected into civil time at the end of June 30th, 2015. This means that the last minute of June 30th, 2015 will have 61 seconds. If a clock is synchronized to the standard civil time, it will show an extra second 23:59:60 on that day between 23:59:59 and 00:00:00. This extra second is called a leap second. There have been 25 such leap seconds since 1972. The last one took place on June 30th, 2012.
Not all applications and systems are properly coded to handle this “:60” notation.
Today at 16:53:20 GMT, it’ll be 1,400,000,000 in Unix time.
Contributing Advent 21: Timezone database
Timezones have always been a pain, and Daylight Saving(s) time does not make it a lot easier. Then of course you have governments that decide to change the rules. Often that is done nicely in advance, but once in a while the rule changes are announced at the absolutely last moment, or, sometimes even after the new rules have come into effect. To track the craziness, have a look at Time Zone News, and this image to see how many different rules there are!
So, does anybody else think that 24x7x365=7 years?
Coding, Fast and Slow: Developers and the Psychology of Overconfidence
This is an excellent take on why (we the) developers suck at time estimations. Basically, it boils down to two reasons: unknown details of the project and overconfendence.
First off, there are, I believe, really two reasons why we’re so bad at making estimates. The first is the sort of irreducible one: writing software involves figuring out something in such incredibly precise detail that you can tell a computer how to do it. And the problem is that, hidden in the parts you don’t fully understand when you start, there are often these problems that will explode and just utterly screw you.
And this is genuinely irreducible. If you do “fully understand” something, you’ve got a library or existing piece of software that does that thing, and you’re not writing anything. Otherwise, there is uncertainty, and it will often blow up. And those blow ups can take anywhere from one day to one year to beyond the heat death of the universe to resolve.
Read the whole thing, it’s worth it.
Real-time clock, with builders. Video
This is absolutely awesome!
70 workers are building a wooden 4 x 12 m “digital” time display in real time: a work that involves 1611 changes within 24 hour period.
Seamlessly documented and shot on video, a 24 hours movie or clock is now available.
Standard Time is an artwork of Mark Formanek, realized by Datenstrudel.
A few websites around the web have it synchronized to the actual time…