4 ms·

ISO-8601 is not the correct format for serializing local time unless it's in the past. In my experience, a local datetime picker is going to be used almost exc

ISO-8601 is not the correct format for serializing local time unless it's in the past. In my experience, a local datetime picker is going to be used almost exclusively for a future date and time. What you want instead of a timezone offset is a zone ID. That way date and tzdata can handle it properly on the backend.

progmetaldev 2y ago
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
ibejoeb 2y ago
Right. The offset is not enough without a reference recorded time. You need the time and the time zone in order know the true time. This is a big problem is systems that don't have an intrinsic time type that deploy and have a database full of ambiguous times. Once it happens, backfilling that is a real slog.

progmetaldev 2y ago

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

ibejoeb 2y ago

Right. The offset is not enough without a reference recorded time. You need the time and the time zone in order know the true time. This is a big problem is systems that don't have an intrinsic time type that deploy and have a database full of ambiguous times. Once it happens, backfilling that is a real slog.