This is why you store two dates: what the user sent and what you need for calculations. What the user sent becomes your oracle and what you show the user (date time + timezone) and your derived utc to do datetime arithmetic
This is why you store two dates: what the user sent and what you need for calculations. What the user sent becomes your oracle and what you show the user (date time + timezone) and your derived utc to do datetime arithmetic
If the UTC is derived why store it (unless just as a performance concern e.g. materialised view type of thing)
Presumably if the conversion logic changes. Eg user enters a future date in a place but the timezone in that place changes in the future.
That's a good point although I would prefer to have a deterministic conversion that handles historic changes. But I get the point and having a source of truth for the conversion could be better as it won't be affected by bugs in the conversion of deemed right. It does mean maintaining two values though.