5 ms·
This is a really good point and I don't disagree with it. I'd tend to prefer to store in UTC and store the associated timezone separately.
by powvans 10y ago
This is a really good point and I don't disagree with it. I'd tend to prefer to store in UTC and store the associated timezone separately.
- mkj 10y agoThe problem with that is you don't know what UTC is going to be in the future for a certain place and time.
- jeff_tyrrill 10y ago> I'd tend to prefer to store in UTC and store the associated timezone separately. This is exactly the wrong approach for calendaring software, because it results in appointments moving in time when governments change the daylight saving time rules. Storing in a local time (plus time zone) is exactly right for calendaring. And the correct-sounding, but wrong, mantra of "always store in UTC" is why calendaring apps handled the change so poorly.
- alfalfasprout 10y agoDepends on where you're storing it. If you're using a sensible RDMS like Postgres, there's a 'Timestamp with Time Zone' data type which will internally store the time as UTC but keep track of the offset for you.