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.
- Go back to storing local times and just do some extra work when I integrate with other systems that use UTC.
- 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?