This post is archived and probably outdated.

UTC isn't always the answer for storing dates

2020-06-26 00:41:00

When looking through online forums at date related questions a typical advice is like this:

Store dates in UTC and convert to a local timezone on display.

For many cases this is the absolute right choice. So if this is a date when an article was published it's useful for users to get their local time.

However we all know it - there never is a single true answer and the correct answer always is "it depends." An example:

You are building a system for booking a concert hall. Such tickets can be a bit in the future and have a printed time. Also there are other processes depending on that time (catering staff and security have to be in time etc.)

When storing this date in UTC all will be fineat first, browsing through the calendar will look fine and if somebody comes from across the timezone border they can see their local time. Nice.

Now politics come into play and change the rules for daylight saving times. Suddenly your event is one hour off. Sad.

And yes, these things happen. For instance:

Thus, if the local time is important the advice to store UTC might not be so good, but rather store date, time and timezone. Best form for storing the timezone is not in the common abbreviation like "CEST" or "ET" which can be ambiguous (AST could be Arabian Standard Time UTC+3h or Atlantic Standard Time UTC-4h) but in the form used by the IANA tz database as Europe/Berlin or America/New_York.