I always found it weird when systems code dates as DateTime strings. There needs to be a different primitive for Date, which is inherently timezone-less, and DateTime, which does require a timezone.
After having a bunch of problems with dealing with Dates coded as DateTime, I've begun coding dates as a Date primitive, and wrote functions for calculation between dates ensuring that timezone never creeps its way into it. If there is ever a DateTime string in a Date column in the database, it's impossible to know what the date was supposed to be unless you know you normalized it at some point on the way up.
Then I found that a lot of DatePicker libraries, despite being in "DATE" picker mode, will still append a local timezone to its value. So I had to write a sanitizer for stripping out the TZ before sending up to the server.
That said, I am pretty excited about Temporal, it'll still make other things easier.
There needs to be a difference between an Instant, an Instant at an Observed Location, and a 'Specification for constructing a date that might or might not have already passed or pass in the future'.
E.G. in a conversation "Lets open the shop at 9am every day that it isn't closed." Is a fairly simple recurrence, with some exceptions*. If timezones change the scheduled time remains evaluated again on each day.
Temporal does have PlainDate, which is the Date primitive you're describing (by a different name, presumably to not collide with the old Date type).
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...