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).
Define “valid”.
It’s not always unambiguous, for one thing. A given local time can map to 0, 1 or 2 UTC times:
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.