Glad OP discussed daylight savings nightmare.

But I hate how when I stack my yearly weather charts, every four years either the graph is off by one day so it is 1/366th narrower and the month delimiters don't line up perfectly, or i have to duplicate Feb 28th so there is no discontinuity in the lines. Still not sure how to represent that, but it sure bugs me.

Nice post. I think about time... all the time haha. There's another source you might enjoy (Re: your NTP and synchronization question) from TigerBeetle: [Implementing Time](https://www.youtube.com/watch?v=QtNmGqWe73g)

> other epochs work too (e.g. Apollo_Time in Jai uses the Apollo 11 rocket landing at July 20, 1969 20:17:40 UTC).

I see someone else is a Vernor Vinge fan.

But it's kind of a wild choice for an epoch, when you're very likely to be interfacing with systems whose Epoch starts approximately five months later.

Time is a mess. Always. The author only scratched the surface on all the issues. Even if we exclude the time dilation of relativity which affects GPS/GNSS satellites - independent of if it is due to difference in gravitational pull or their relative speed over ground, it's still a mess.

Timezones; sure. But what about before timezones got into use? Or even halfway through - which timezone, considering Königsberg used CET when it was part of Germany, but switched to EET after it became Russian. There's even countries that have timezones differenting by 15 minutes.

And dont get me started on daylight savings time. There's been at least one instance where DST was - and was not - in use in Lebanon - at the same time! Good luck booking an appointment...

Not to mention the transition from Julian calendar to Gregorian, which took place over many, many years - different by different countries - as defined by the country borders at that time...

We've even had countries that forgot to insert a leap day in certain years, causing March 1 to occur on different days altogether for a couple of years.

Time is a mess. Is, and aways have been, and always will be.

  An IANA timezone uniquely refers to the set of regions that not only share the same current rules and projected future rules for civil time, but also share the same history of civil time since 1970-01-01 00:00+0. In other words, this definition is more restrictive about which regions can be grouped under a single IANA timezone, because if a given region changed its civil time rules at any point since 1970 in a a way that deviates from the history of civil time for other regions, then that region can't be grouped with the others

  % zdump -i Europe/Warsaw | head
  
  TZ="Europe/Warsaw"
  - - +0124 LMT
  1880-01-01 00 +0124 WMT
  1915-08-04 23:36 +01 CET
  1916-05-01 00 +02 CEST 1
  1916-10-01 00 +01 CET
  1917-04-16 03 +02 CEST 1
  1917-09-17 02 +01 CET
  1918-04-15 03 +02 CEST 1
  % zdump -i Europe/Kaliningrad | head -20
  
  TZ="Europe/Kaliningrad"
  - - +0122 LMT
  1893-03-31 23:38 +01 CET
  1916-05-01 00 +02 CEST 1
  1916-10-01 00 +01 CET
  1917-04-16 03 +02 CEST 1
  1917-09-17 02 +01 CET
  1918-04-15 03 +02 CEST 1
  1918-09-16 02 +01 CET
  1940-04-01 03 +02 CEST 1
  1942-11-02 02 +01 CET
  1943-03-29 03 +02 CEST 1
  1943-10-04 02 +01 CET
  1944-04-03 03 +02 CEST 1
  1944-10-02 02 +01 CET
  1945-04-02 03 +02 CEST 1
  1945-04-10 00 +02 EET
  1945-04-29 01 +03 EEST 1
  1945-10-31 23 +02 EET
  %

... humans don't generally say

"Wanna grab lunch at 1,748,718,000 seconds from the Unix epoch?"

I'm totally going to start doing that now.

I think this is one of my favourite write ups on HN for a while. I miss seeing more things like this.

It is a pet peeve of mine, but any statement that implies that Unix time is a count of seconds since epoch is annoyingly misleading and perpetuates such misconception. Imho better mental model for Unix time is that has two parts, days since epoch * 86400, and seconds since midnight, which get added together.

Obligatory falsehoods programmers believe about time:

https://gist.github.com/timvisee/fcda9bbdff88d45cc9061606b4b...

In a nutshell if you believe anything about time, you're wrong, there is always an exception, and an exception to the exception. And then Doc Brown runs you over with the Delorean.

Two things that aren't really covered:

- system clock drift. Google's instances have accurate timekeeping using atomic clocks in the datacenter, and leap seconds smeared over a day. For accurate duration measurements, this may matter.

- consider how the time information is consumed. For a photo sharing site the best info to keep with each photo is a location, and local date time. Then even if some of this is missing, a New Year's Eve photo will still be close to midnight without considering its timezone or location. I had this case and opted for string representations that wouldn't automatically be adjusted. Converting it to the viewer's local time isn't useful.

> What explains the slowdown in IANA timezone database updates?

My guess is that with the increasing dependency on digital systems for our lives the edge-cases where these rules aren't properly updated cause increased amounts of pain "for no good reason".

In Brazil we recently changed our DST rules, it was around 2017/2018. It caused a lot of confusion. I was working with a system where these changes were really important, so I was aware of this change ahead of time. But there are a lot of systems running without too much human intervention, and they are mostly forgotten until someone notices a problem.

Very nice write up! But I think your point that time doesn't need to be a mess is refuted by all the points you made.

I know you had to limit the length of the post, but time is an interest of mine, so here's a couple more points you may find interesting:

UTC is not an acronym. The story I heard was the English acronym would be "CUT" (the name is "coordinated universal time") and the French complained, the French acronym would be "TUC" and the English-speaking committee members complained, so they settled for something that wasn't pronouncable in either. (FYI, "ISO" isn't an acronym either!)

Leap seconds caused such havoc (especially in data centers) that no further leap seconds will be used. (What will happen in the future is anyone's guess.) But for now, you can rest easy and ignore them.

I have a short list of time (and NTP) related links at <https://wpollock.com/Cts2322.htm#NTP>.

The absl library has a great write up of time programming: https://abseil.io/docs/cpp/guides/time

The way Google implemented leap seconds wasn't by sticking a 23:59:60 second at the end of 31st Dec. The way they did it was more interesting.

What they did instead was to "smear" it across the day, by adding 1 / 86400 seconds to every second on 31st Dec. 1/86400 seconds is well within the margin of error for NTP, so computers could carry on doing what they do without throwing errors.

Edit: They smeared it from noon before the leap second, to the noon after, i.e 31st Dec 12pm - 1st Jan 12pm.

It’s quite different from how I think about time, as a programmer. I treat human time and timezones as approximate. Fortunately I’ve been spared from working on calendar/scheduling for humans, which sounds awful for all the reasons mentioned.

Instead I mostly use time for durations and for happens-before relationships. I still use Unix flavor timestamps, but if I can I ensure monotonicity (in case of backward jumps) and never trust timestamps from untrusted sources (usually: another node on the network). It often makes more sense to record the time a message was received than trusting the sender.

That said, I am fortunate to not have to deal with complicated happens-before relationships in distributed computing. I recall reading the Spanner paper for the first time and being amazed how they handled time windows.

We don’t have much trouble yet with relativistic temporal distortions, but Earth’s motion causes us to lose about 0.152 seconds per year relative to the Solar system. Likewise we lose about 8.5 seconds per year relative to the Milky Way. I wonder when we’re going to start to care. Presumably there would be consideration of such issues while dealing with interplanetary spacecraft, timing burns and such.

I never really took time seriously until one of my cron jobs skipped execution because of daylight saving. That was the moment I realized how tricky time actually is. This article explains it really well. The part about leap seconds especially got me. We literally have to smear time to keep servers from crashing. That’s kind of insane.

I’m all about monotonic time everywhere after having soon too many badly configured time sync settings. :)

I never really took time seriously until one of my cron jobs skipped execution because of daylight saving. That was the moment I realized how tricky time actually is.

This article explains it really well. The part about leap seconds especially got me. We literally have to smear time to keep servers from crashing. That’s kind of insane.