←back to thread

189 points rmason | 1 comments | | HN request time: 0s | source
Show context
codr7 ◴[] No.44377905[source]
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.
replies(1): >>44378162 #
bloppe ◴[] No.44378162[source]
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.

replies(2): >>44379169 #>>44380913 #
1. codr7 ◴[] No.44379169[source]
Yep, there's an astonishing amount of pretending involved in dates/time processing,

I'm surprised anything works at all just from what I know.