0

I'm working on a system that will be used in a single time zone only, but integrates with other systems that exposes dates and times in UTC, so we thought that we go UTC all the way as well. We've also heard from before that storing your times in UTC is the way to go anyway, so it felt like the easiest path to minimize troubles.

Recently though, we ran into some trouble. We are logging events in the system which are of value to the user, so we let the user search and view them. Sweden is in a +1 timezone so an event at 0900 local time will be stored as 0800 UTC time. When showing the events to the user we can successfully transform them back to local time until very recently when daylight savings kicked in. Translating 0800 UTC to local time will now add 2 hours. The logged event now appears to have happened at 10:00. How should I handle this?

In this case, where the stored time is the same time as the time it was actually saved to DB, I could just look at the date and adjust it depending on if DST was on or off at that particular time. However, I think I need a generic solution for this, since there will be timestamps created at various times (at other places) in the system that need to represent future and past points in time. To me it looks like I have 2 options.

  1. Go back to storing local times and just do some extra work when I integrate with other systems that use UTC.
  2. Along with each UTC timestamp store some data that can tell me if a timestamp was created during DST or not.

Am I wrong? Right? Missing something?

  • Usually, timestamps are stored as UTC timestamp+the user's offset from UTC when the timestamp was taken. It allows to implement all kinds of human-intuitive behaviour. – Joker_vD Apr 17 '16 at 11:15
  • That's what I was thinking, but I've never before seen a database where every datetime column have an accompanying offset column, which made me believe I was missing something. – Mattias Nordqvist Apr 17 '16 at 12:32

2 Answers2

0

You can always get the client timezone offset using the getTimezoneOffset method. Now all that's left is to apply this timezone offset to the UTC date stored in your database and display the correct date to the end user. If on the other hand you need to display the timezone offset used by the user when the event was recorded in your database then you definitely an additional column in your DB to record this offset. Things get tricky when you want to handle multiple timezones: what happens when you want to display a record to a user in India that was submitted by a user in Sweden?

Darin Dimitrov
  • 1,023,142
  • 271
  • 3,287
  • 2,928
  • Careful about this approach. the call to `getTimezoneOffset` should be made against the specific UTC date and time. It's all too common for one to call `new Date().getTimezoneOffset()` and applying the result to an arbitrary value, forgetting that this is the *current* offset, which may be quite different from the time in question. – Matt Johnson-Pint Apr 18 '16 at 00:57
0

The main thing you are missing is that you cannot just think of Sweden as a +1 time zone. A time zone and a time zone offset are two very different things. Read the timezone tag wiki for more details on this.

Instead, you can take one of the two following approaches:

  1. Think about the time zone in terms of it's IANA tzdb identifier. For Sweden, use Europe/Stockholm. Do your conversions between UTC and local time using this time zone, using a language, library, or platform that implements the tz database.

  2. Instead of figuring out what the client-side time zone is, rely on the client-side operating system to do the conversions to local time. Most environment (including JavaScript in a web browser) can convert from UTC to local time and vice-versa. With this approach, transmit only UTC times between the client and the server.

Also, you didn't ask in the question, but in your title you mentioned future events. That is a very different scenario, and often requires you capture the local time and IANA time zone. See this answer for more details.

You may also wish to read Daylight saving time and time zone best practices.

Community
  • 1
  • 1
Matt Johnson-Pint
  • 230,703
  • 74
  • 448
  • 575