The <select> element can now be customized with CSS

<input type="datetime-local"> with automatic ISO8601 timezone offsets would be awesome too!

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.

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.

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.

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.

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).

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_datetimefor...

or appending the `Date().getTimezoneOffset();` to receive a ISO8601 timezone offset