How to Think About Time in Programming

Plenty of people these days insist on stamping anything that looks like time with a time zone. Getting that right through the entire stack is like winning the lottery imo. When dealing with different time zones, I've had some success in simplifying the situation by mandating UTC for the server side.

I think the more insidious and fundamental issue is that there are a plethora of subtly different clocks that everyone calls "UTC". A real UTC clock has an occasional 61-second minute. A leap second would read 11:59:60. So that day would have 86401 seconds instead of the usual 86400.

Software engineers understandably don't like that, so Unix time handles it instead by "going backwards" and repeating the final second. That way every minute is 60 seconds long, every day is 86400, and you're only at risk of a crazy consistency bug about once every year and a half. But most databases do it differently, using smearing. Many databases use different smearing windows from one another (24 hours vs 20 for instance). Some rarer systems instead "stop the clock" during a leap second.

That's 4 different ways to handle a leap second, but much documentation will use terms like "UTC" or "Unix time" interchangeably to describe all 4 and cause confusion. For example, "mandating UTC for the server side" almost never happens. You're probably mandating Unix time, or smeared UTC.

Does this disagreement cause any problems though?

If you care about sub-second differences, you likely run your own time infra (like Google Spanner), and your systems are so complex already that the time server is just a trivial blip.

If you are communicating across org boundaries, I've never seen sub-second difference in absolute time matter.