4 ms·

How would the runtime know that though? If you're in a plane with no internet, or if you're privacy conscious and you have location services turned off, there's

How would the runtime know that though? If you're in a plane with no internet, or if you're privacy conscious and you have location services turned off, there's no way for the JS engine to know you're in a different timezone. I mean your argument has some merit but I'd argue that "you get the new timezone if you create a new date after your system updates its local timezone" is good enough. Furthermore, most applications will just use UTC; local timezone is more used to adjust the displayed time, and even then it's opt in (e.g. someone reading a log will want server time or UTC, someone using a calendar will want to see their local time OR the time at the location of an event, etc).

lxgr 2y ago
> someone reading a log will want server time or UTC I personally prefer local times when reading logs, but I'll absolutely take UTC over a wrong local time.
TheAceOfHearts 2y ago
The operating system is responsible for tracking timezone changes. If you turn off automatic timezone switching or you're in an airplane without internet then the timezone change just won't be detected, which is perfectly fine. That isn't an argument against supporting a timezonechange event. Every major operating system has had a way to keep track of timezone changes going back over 25 years. This was during the era where most people were on desktops, but now most people are on mobile devices so it's more relevant than ever. Chromium already has a time_zone_monitor service in place, which I linked in a different reply. Currently, if you want to detect that the timezone has changed you have to poll `Intl.DateTimeFormat().resolvedOptions().timeZone` and `new Date().getTimezoneOffset()`. An event would just let you get notified without requiring polling. Updating the displayed time on the client is precisely one of the reasons that this feature can be desirable.

lxgr 2y ago

> someone reading a log will want server time or UTC I personally prefer local times when reading logs, but I'll absolutely take UTC over a wrong local time.

TheAceOfHearts 2y ago

The operating system is responsible for tracking timezone changes. If you turn off automatic timezone switching or you're in an airplane without internet then the timezone change just won't be detected, which is perfectly fine. That isn't an argument against supporting a timezonechange event. Every major operating system has had a way to keep track of timezone changes going back over 25 years. This was during the era where most people were on desktops, but now most people are on mobile devices so it's more relevant than ever. Chromium already has a time_zone_monitor service in place, which I linked in a different reply. Currently, if you want to detect that the timezone has changed you have to poll `Intl.DateTimeFormat().resolvedOptions().timeZone` and `new Date().getTimezoneOffset()`. An event would just let you get notified without requiring polling. Updating the displayed time on the client is precisely one of the reasons that this feature can be desirable.