3 ms·
Well, when it's not time, just some numbers. The most you can do is to store as is, hoping to figure out what that means later. Also, even if all inputs and ou
by out_of_protocol 3y ago
Well, when it's not time, just some numbers. The most you can do is to store as is, hoping to figure out what that means later.
Also, even if all inputs and outputs are in local time, it still makes sense to process everything in UTC. There are a lot of weird corner cases making math on datetime really complicated
- growse 3y agoThis doesn't work reliably for future timestamps. If a user submits a local timestamp and you then convert it to UTC, you're using the current definition of what we think that offset will be at that future time. However, timezone definitions change. By doing the conversion, you've got to remember to check that the offset between what you stored and the user's local hasn't changed since the time you did the conversion. How often and when you do this checking is ... not obvious.
- out_of_protocol 3y agoUTC or unix timestamp gets you moment of time. You know exactly moment event happened. Definitions can change, but usually not retroactively. TZdata is a database of such changes, and stores definition changes, basically all *nix OSes depend on it to cast moment of time into timezone. You can always convert timestamp in the past into desired timezone. If you work with calendars and want you know what "04:00 tomorrow" means - good luck, you'll need it. as example, "04:00 tomorrow" may not exist at all
- out_of_protocol 3y ago* ignoring leap seconds