Storing UTC is not a silver bullet (2019)

This article always bugged me, because it needlessly makes things seem complicated. There are times when you are trying to represent a moment in time, and then there are times when you are trying to represent a moment in a calendar (which is not the same as a moment in time). It's all about capturing intent and using the right tool for the job.

The moment in time case is pretty straightforward. The moment in a calendar case can get horribly complex because calendars are... very human constructs, and there are challenges capturing the entirety of human intent (did you mean for the position on the calendar to remain fixed even if the calendar changes? what about leap seconds? etc.), because often humans aren't even sure about their intent.

> So from November 1st 2021 onwards, the UTC offset of each country will be fixed – but there may be countries which currently always have the same offset as each other, and will have different offsets from some point in 2021. (For example, France could use winter time and Germany could use summer time.)

It’s worth noting that this did not end up happening. Maybe a 2019 tag could be added to the title?

The short of it is that using UTC for events in the past is usually OK (you can at any moment recalculate the wall clock time in the past with UTC plus location data), but not for future events (e.g. scheduling, opening hours). Because the intent of stored future datetimes is almost always the wall clock time in the location where the event takes place. If TZ rules change for that location the intent is to pin the event to the local time rather than to UTC. For disambiguation, future events should ideally include location as well as datetime, though this is often omitted / implicit.

The remaining edge cases are future events that span different time zones (e.g. scheduled calls with participants from different TZs). If one of the timezone rules chances, this can only really be resolved by rescheduling and updating the info for the participants.

Jon Skeet is one of the two greatest of my software engineering heroes. The other one is Andrew Hejlsberg.

Just by reading some of his answers on SO, or by reading his C# in depth book, or his talks and blogs, I learned how you can think of scenarios where a design falls short, and to think of pros and cons rather than right and wrong. He has a clear mind on things, and a very direct style of writing.

I think the whole article can be generalized as following: one cannot make assumptions about relative values.

You can replace UTC with US dollars and Amsterdam time with euros and talk about conference prices. If you convert 100 euro to US dollars at the time of record creation, the price at the day may not be 100 euros anymore.

Ideally you record a tuple that allows to define value unambiguously (e.g. time 2022-02-21 9:00 timezone Europe/Amsterdam) because in this case you can always resolve the absolute time value later.

This is a typical hiccup for any business expanding into multiple locations with different parameters (time zones, currencies, units etc).

Once case that I find particularly interesting is an event that happens in different locations at the same logical (but different absolute time). Let's say you want to send an email to all your users across the global on Monday 9:00. If you want to add up to complexity, you could think about sending an email to all your users across the globe on the first working day next week.

Storing UTC for future times has never made much sense. But people still think UTC is the silver bullet for storing timestamps, ie. for records of past events. But even this is prone to failure. At some point someone will ask the question "how many events happened before lunch time?" This is a very clear and reasonable question to ask, but when is lunch time?

Unfortunately many implementations simply store the UTC timestamp and throw away any time zone information (e.g. postgres TIMESTAMP WITH TIME ZONE, despite the misleading name). There are two ways around it: store the user's current time zone in another field, or record it in something like ISO8601 as local time with offset (although this only records the offset, not the IANA time zone). Both options have pros and cons.

I wish implementations supported the basic tuple of (timestamp, timezone) where timestamp is a Unix-style timestamp (a number). The timezone can be ignored when it isn't needed, but is always there when it is. The difficulty is how to store the timezone and I'm sure there are numerous other issues with this.

There was some interesting discussion around what data structures you should store at https://news.ycombinator.com/item?id=40933110 (Engineering principles for building financial systems).

Almost always you store some kind of log with timestamps when decisions were made or events generated or whatever.

Is there any library that can translate utc to local time where it addresses time offset changes based on the knowing the utc when the future time was decided upon?

We should just drop all other time zones and use UTC

I always use TIA internally nowadays. Continuous, no leap seconds, no problems.

Honestly, the moment your time handling library tries to address all the things a calendaring application could quite reasonably want to do, you're going to end up with an unsatisfying solution.

After all, if I schedule a weekly recurring video call at 9:00 in City A, aka 14:00 in City B, then daylight savings starts in City A but not City B then either the meeting shifts to 13:00 in City B, or to 10:00 in City A.

No amount of clever date representation can sidestep the fact that the meeting has moved by an hour for some attendees but not others.

If you want to represent a point in time, use UTC. If you want to represent a point in a calendar, use local timezone.

Ultimately, the issue is separating and capturing user intent between two major categories:

1. Events that are socially bound to a context, and capturing that contract or triggering rules, e.g. "Whenever the nation of Ruritania declares March 3rd end of workday".

2. Events that occur a fixed and knowable internal from "now."

It is complicated further by the fact that many users won't really be aware of their own varying different intentions.

Is anyone else sick of the "European Parliament" deciding the rules for the rest of the Internet? I know I sound like a dumbass American here, but I feel like there's gotta be a way for the EU to get what they want without bothering everyone else in the world constantly...

The issue is that they keep enacting laws that have good intentions, but are written poorly and without any sort of experience in the technical realm. This results in the laws' implementation being filled with weird loopholes that you can use to get around the extra work while still maintaining the legality, but completely missing the intention of the law in the first place. It just seems like a massive waste of time to me.