and then you can read it out to indirectly get the time zone anyway (albeit a less specific version of it, since you wouldn't have the DST info). also, sometimes you need to actually have the users time zone for things like e.g. scheduled blog posts, so that they will show up when the user expects them to, not their scheduled time in UTC or whatever.
I use a site that only does UTC, and time zone related complaints are the most common issue asked about on the forums
> IE, web component where you can set a format string and then the browser renders it substituting the info it has?
you can easily detect this
- please display this localdatetime as a string
- read it back and parse it
- are they (almost) exactly multiples of 60 minutes apart?
- if yes it's most probably your timezone
because websites are sometimes interactive and allow the user to schedule things to happen at certain times.
And displaying time/date locally would leak that information anyway if you wanted to do it in a way that works in various contexts it would need to in a website (e.g. canvas based apps)
even if you just let the user stylize the font of the date (which you clearly would need to), you tell your magic date input to only show the current hour, then use a font that has a certain width for each number, allowing you to then based on the width of that element figure out the hour, same for other things, obviously. It's easy to imagine some thing like that without thinking about all the details, but it's not really feasible once you think about how this would be implemented and how it could be circumvented. And that's in addition to not working in contexts where you schedule a blog post, zoom meeting, or whatever else might require the server to account for user time zone
IE, web component where you can set a format string and then the browser renders it substituting the info it has?
Then sites that need to know the date can ask for it.
There's a lot we could do by splitting stuff into permissions and some sort of standard templates.