Hacker News new | ask | show | jobs
by Arnavion 3304 days ago
If the software converts to UTC it should be using the expected local timezone on the target date (4pm Tuesday), not the current timezone. So this will only be a problem if the TZ tables for the future are not correct (which happens, as noted in sibling comments, but is not as widespread as every DST event like your comment seems to imply).
1 comments
manigandham 3304 days ago
> expected local timezone

I'm not sure what this means. Either way, to store an appointment for a certain user, you need the local timezone of that user and the local timestamp. UTC version of that timestamp is optional (maybe for easier calculations in the database), but you must have the local timestamp to convert correctly.

Local TZ => UTC is a formula that is not constant. You cannot store the output of this formula and expect to reverse and get back the original input precisely because of the changing formula.

link
Arnavion 3304 days ago
>I'm not sure what this means.

The timezone that the user will experience on that date.

>Either way, to store an appointment for a certain user, you need the local timezone of that user and the local timestamp.

Correct. I did not disagree with this.

>Local TZ -> UTC is a formula that is not constant. You cannot store the output of this formula and expect to reverse and get back the original input precisely because of the changing formula.

Also correct. But as I said, your original comment implied this is a concern for all DST events which is not true. It is only a concern when the time was converted using some DST assumption and then that assumption is invalidated (eg the software decided to convert "4pm Tuesday local" to UTC assuming the timezone on Tuesday will be UTC+7, but the DST change happens to come early this year and in fact it's UTC+8 on Tuesday).

Regardless, I agree that taking this risk is not correct. Such a time should not be converted to UTC to begin with. Better to store the original local time.

link
manigandham 3304 days ago
Yes, it is trivial extra work and storage for a timezone + timestamp (along with optional UTC) to get 100% reliable calculations.

Timezones, especially globally, have enough updates being made that they are not something worth the risk just to save a few bytes.

link