3 ms·

Storing local time is fine if you and your server never ever leave your timezone. You can even get away with it for a long time. If your logic does ever require

by lhorie 7y ago

Storing local time is fine if you and your server never ever leave your timezone. You can even get away with it for a long time. If your logic does ever require timezone conversions down the line though, it will most likely surface some nasty problems. And when I say nasty, I mean it in the will-leave-a-battle-scar-that-your-future-graybeard-self-will-warn-younguns-about sense. The thing with the UTC advice and those who don't listen to it is that people often don't realize that both DST policy changes and factors that increase the number of applicable timezones in a business are rare to begin with. They often think that that storing local time is safe because they never had to truly deal with the complexities of representing physical time. But DST policy changes are much rarer than factors that fuck up local time based implementations, and issues can be fixed without huge schema changes and downtimes. Plus it's less likely you will actually need to fix them since higher-ups won't be able to grasp the issue, whereas a local time bug fix will often come as a demand from some higher-up suit who flew out of state.

wvenable 7y ago
I've said all over this thead to store local time and the associated timezone. You do that and no nasty problems can happen. And you are correctly storing the time that the user intended and not the time it might be converted into.
- lhorie 7y ago
  If you're storing the timezone (and by that I assume you're doing so unambiguously, because offset alone doesn't tell you hemisphere/DST rules, and timezone names are not unique), then you're effectively using UTC, albeit storing it in a non-normalized format. The flaw in your logic is in assumption that "intended time" is always fixed relative to one user's clock time. For international events, intended time is physical time. If it's a friday and I verbally arrange a meeting with someone in Sao Paulo at 3pm BST the following monday and that translates to 11am PST today for me at San Francisco, but if there's a DST change for me over the weekend, the intended time is still 3pm BST, not 11am PST, because in such cases, the general logical expectation is that whoever is getting a time change is the one who should be on top of it. In either case, you'd be able to recover "intended time" (for any meaning of the term) 99.9999% of the time regardless of whether you used UTC or local time+timezone. If there was indeed an unlikely event of an unannounced DST policy change, then whether intended time is wrong depends on who's affected. If it's an international meeting and intended time means physical time, then local time+timezone does not capture true intended time. Likewise, if intended time means local time for a single user, UTC will be the wrong one. But as I said, this case is vanishingly unlikely. A lot of code doesn't handle integer overflows correctly because they are unlikely too and the world is still humming along just fine.

by lhorie 7y ago

wvenable 7y ago

I've said all over this thead to store local time and the associated timezone. You do that and no nasty problems can happen. And you are correctly storing the time that the user intended and not the time it might be converted into.

lhorie 7y ago
If you're storing the timezone (and by that I assume you're doing so unambiguously, because offset alone doesn't tell you hemisphere/DST rules, and timezone names are not unique), then you're effectively using UTC, albeit storing it in a non-normalized format. The flaw in your logic is in assumption that "intended time" is always fixed relative to one user's clock time. For international events, intended time is physical time. If it's a friday and I verbally arrange a meeting with someone in Sao Paulo at 3pm BST the following monday and that translates to 11am PST today for me at San Francisco, but if there's a DST change for me over the weekend, the intended time is still 3pm BST, not 11am PST, because in such cases, the general logical expectation is that whoever is getting a time change is the one who should be on top of it. In either case, you'd be able to recover "intended time" (for any meaning of the term) 99.9999% of the time regardless of whether you used UTC or local time+timezone. If there was indeed an unlikely event of an unannounced DST policy change, then whether intended time is wrong depends on who's affected. If it's an international meeting and intended time means physical time, then local time+timezone does not capture true intended time. Likewise, if intended time means local time for a single user, UTC will be the wrong one. But as I said, this case is vanishingly unlikely. A lot of code doesn't handle integer overflows correctly because they are unlikely too and the world is still humming along just fine.