Are UTC and local time interchangeable in a location that has day light savings?

Question

I know we should store time in UTC in our databases, but I'm having a hard time to get support from my team to adopt this because of the followings:

• we never deal with internaltional time stamps
• we have day light savings but we always display localtime, no need to store in UTC
• the burden to data wearhouse is huge since conversions are required now
• we consume external data and they are not in UTC, it'll cause extra work for others
• our business users never asked

I have two questions here.

• If we convert our existing local time to UTC, will that always result in valid datetime stamps? I have heard that conversion from UTC to local times are always valid. But conversion from local time to UTC may not.
• I can't think of any other pro UTC arguments except it's the right thing to do and UTC time is always valid.

For most of the usage, these times will be used for display purposes and also run reports aganist (start date and end date). Some business users have direct read access to them as well (they like local time).

Answer 1

If we convert our existing local time to UTC, is that a valid conversion?

Define "valid".

It's not always unambiguous, for one thing. A given local time can map to 0, 1 or 2 UTC times:

• 0 mappings if the local time is skipped, e.g. 1.30 when local time goes from 1am to 2am due to a DST transition "spring forward". This shouldn't happen if it's meant to be a valid local time, of course, but if you have something like a weekly event, you could end up with invalid local times inadvertently.
• 1 mapping if there are no DST transitions involved
• 2 mappings if the local time is ambiguous, e.g. 1.30 when local time goes from 2am back to 1am due to a DST transition "fall back"

Fundamentally, local time is harder to reason about when you need to think about DST transitions. 12.30am + 1 hour isn't always 1.30am, for example.

Personally I think you should try to model whatever the times you're given really represent. Sometimes that's local time with a particular offset from UTC; sometimes it's really not a human time at all, but a timestamp with an arbitrary scale and epoch. I've written a bit about this in the Noda Time user guide.

You haven't really told us about what you need to do with these times. Do you need to perform any kind of arithmetic? Comparisons? Recurrences? Displaying to the user? Potentially displaying to users in other time zones? It's very hard to make any concrete recommendations without that sort of information.

Answer 2

Storing the time as UTC is the safest way. If you want to store the local time you can do so, if you also store the UTC offset (2012-05-20 05:34 UTC−06:00).

Now the magical central sentence of my Comment: "Time zones are UTC offsets!"

Often people tend to think time zones are geographical defined, but our time zone switches with DST. Europe for example uses Central European Time (CET) in winter and Central European Summer Time (CEST) in summer. Namibia is on the same longitude as Europe, they look like the use the same time zone and both use DST. But Namibia and Europe will never have the same local time because Namibia is on the south side and it does it vice versa.