3 ms·
The problem with that is you lose the localtime information, which you may want. Say you have recorded the localtime with the known UTC offset of 0, and that lo
by isleyaardvark 1y ago
The problem with that is you lose the localtime information, which you may want. Say you have recorded the localtime with the known UTC offset of 0, and that localtime is midnight UTC. Now you want to map it back to a localtime in the past. Ok, which localtime? Was it 8pm in NYC? Or was it 5pm in LA? Is the assumption that the localtime is wherever the user is right now, and is that a valid assumption? If the user has traveled to a different timezone, the time is now being converted to a localtime in the past that is different than it actually was when it happened.
edit: another commenter shared this link with an example: https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a-silver-bullet/ https://codeblog.jonskeet.uk/2019/03/27/storing-utc-is-not-a...
I like their "Principle of preserving supplied data".
- ryao 1y ago> If the user has traveled to a different timezone, the time is now being converted to a localtime in the past that is different than it actually was when it happened. I consider this to be a desirable behavior.
- isleyaardvark 1y agoFor most cases I think that would be correct, but I will say if I am looking at my ATM withdrawals for a trip I made to San Francisco, I would like the time shown to be the SF time and not that of my local hometown, and vice versa if I'm in SF.