5 ms·

For this case, I will often ask for the timezone, since that data is often updated on the operating system, but I don't believe it's often for someone to be in

For this case, I will often ask for the timezone, since that data is often updated on the operating system, but I don't believe it's often for someone to be in the same location and have their timezone change. The software that I've maintained the most over the years (since 2009 up to deploying an update today) requires a login, so I have a client account that includes choosing their timezone. I then use that to convert everything to UTC in the database, and when I retrieve the data, I use it to convert UTC back to their local date/time. I felt that it was the best option, since a user moving to a different timezone should still be able to get dates/times back relative to where they have their current timezone set.

mason55 2y ago
This works for things in the past but not things in the future. If I say I want something to happen at 8pm New York City time on January 7, 2028 and then the DST rules for NYC change, I likely still want it to happen at 8pm. Converting to UTC and back to local time loses that information and it will happen at the wrong time.
- progmetaldev 2y ago
  I 100% agree with you, and don't set cron jobs/scheduled tasks this way. I only use this for displaying date/time to users. With that said, I do appreciate the comment, and would have to make sure that if I run scheduled tasks in the future, they are run when the user wishes them to be completed based on when that user sets it to be completed (so would most likely not convert to UTC, and save the timezone with the date/time).
preisschild 2y ago
I'd much rather have it just use the system time, which is already available over a javascript API. I wish it just were included in your html form datetime-local request. https://caniuse.com/mdn-javascript_builtins_intl_datetimeformat_resolvedoptions_computed_timezone https://caniuse.com/mdn-javascript_builtins_intl_datetimefor... or appending the `Date().getTimezoneOffset();` to receive a ISO8601 timezone offset

mason55 2y ago

This works for things in the past but not things in the future. If I say I want something to happen at 8pm New York City time on January 7, 2028 and then the DST rules for NYC change, I likely still want it to happen at 8pm. Converting to UTC and back to local time loses that information and it will happen at the wrong time.

progmetaldev 2y ago
I 100% agree with you, and don't set cron jobs/scheduled tasks this way. I only use this for displaying date/time to users. With that said, I do appreciate the comment, and would have to make sure that if I run scheduled tasks in the future, they are run when the user wishes them to be completed based on when that user sets it to be completed (so would most likely not convert to UTC, and save the timezone with the date/time).

preisschild 2y ago

I'd much rather have it just use the system time, which is already available over a javascript API. I wish it just were included in your html form datetime-local request. https://caniuse.com/mdn-javascript_builtins_intl_datetimeformat_resolvedoptions_computed_timezone https://caniuse.com/mdn-javascript_builtins_intl_datetimefor... or appending the `Date().getTimezoneOffset();` to receive a ISO8601 timezone offset