4 ms·

They should add an event to detect when someone changes timezones. That could be another entry in the "falsehoods that programmers believe about time": programm

They should add an event to detect when someone changes timezones. That could be another entry in the "falsehoods that programmers believe about time": programmers believe that your timezone is fixed during usage. But in reality there are millions of people moving between timezones every day.

nejsjsjsbsb 2y ago
If you are on a plane or ISS you could even be timezoneless.
- jofzar 2y ago
  Iss uses Coordinated Universal Time which is just GMT.
- dtech 2y ago
  I.i.r.c. ISS uses UTC
  - noduerme 2y ago
    UTC for the win
- esafak 2y ago
  Wouldn't you be in the time zone you are traveling over, the same as with other modes of transportation?
  - nejsjsjsbsb 2y ago
    You might but that isn't useful. Basically a web app will show you a time affected by your tailwind and weird geopolitics. (The weird politics are not so bad if you stay in the same time zone just changes 2 times a year)
lblume 2y ago
Where would you expect this event to be used? I don't think most web applications somewhat dependent on time should directly have to listen and respond to these events for the amount of people affected by it just doesn't justify the extra effort, I would assume. Libraries could benefit, of course.
- TheAceOfHearts 2y ago
  To my understanding, it shouldn't require that much effort since browsers should already be keeping track of timezone changes, see Chromium's time_zone_monitor [0]. Browsers could emit a "timezonechange" event on the window. A quick search of gecko-dev shows entries for both WM_TIMECHANGE and NSSystemTimeZoneDidChangeNotification, although they haven't separated it into its own service. I imagine they also track timezone changes for other platforms. [0] https://source.chromium.org/chromium/chromium/src/+/main:services/device/time_zone_monitor/ https://source.chromium.org/chromium/chromium/src/+/main:ser...
- scarface_74 2y ago
  First JavaScript is unfortunately not just for web apps. It’s also for desktop apps. Say my normal work day is from 8-5 and I work in the Eastern time zone. I set my Slack DND to outside those hours. I hop on a plane and go somewhere on the west coast. The perfect case, Slack would notify me of the change and let me decide whether I wanted to adjust the DND to local time or keep it. There are two possible scenarios for me. I could have flown to Seattle for a business meeting and I want to change my DND to local time to be in sync with the rest of the team onsite. The other scenario is that I’m flying to Los Angeles to hang out. But I’m working during the day and I still need to work east code time.
  - klabb3 2y ago
    > First JavaScript is unfortunately not just for web apps. It’s also for desktop apps. A bit of a tangent but I’d say server is bigger than desktop. Like it or not JS (or TS) is the only cross platform development language that’s feasible today if you want to use a single language stack. As much as I despise the JS ecosystem practices and haphazard tooling there is no point trying to put the genie back in the bottle.
noduerme 2y ago
The client's timezone should only matter to the client. There's no condition where their clock matters except to translate a timestamp into their local time (for their convenience). Who cares if they change time zones?
- ninkendo 2y ago
  So that you can update the UI to show the new time zone? Or change the time format to indicate that it’s no longer in the same time zone as the user is in? That’s just off the top of my head, I’m sure there’s more.
  - fkyoureadthedoc 2y ago
    I agree that it would be a nice feature, but I'd really have to be scraping the bottom of the feature barrel before I got to this. Unless my product heavily featured scheduling, or was a clock.
- BoppreH 2y ago
  Sending emails at specific user times, billing (be careful with this one!), scheduling events in the future, reporting it to other users (Microsoft Teams' "it's 20:39 in this user's Timezone").
aetherspawn 2y ago
Suggestion, design your app to not be time zone dependant if at all possible. For example, store dates in UTC and render instantaneously in current time zone.
- mschuster91 2y ago
  > and render instantaneously in current time zone And for that you need to have a timezone-change event, if you don't want to poll the current system timezone.
- wim 2y ago
  That only works for past events, not future ones. Converting to UTC is lossy so rendering timestamps correctly in the future becomes problematic with DST/TZ rule changes.
  - lxgr 2y ago
    Really depends on what you want to do. If it's something like "set the date at which new system behavior x becomes effective", UTC is perfectly fine; for scheduling a meeting, not so much.
  - sureIy 2y ago
    > Converting to UTC is lossy How so? UTC is a constant point in time. The difficulty lies in representing the value correctly, but the point in time is unchanged. Unlike what sibling comment mentioned, if an appointment is scheduled at 1739287704987, the value will be the same regardless of where and when it's accessed from.
    - burntsushi 2y ago
      Yes, but they're saying that only works for past events. If you book a dentist appointment in the future using a timestamp, but then the tzdb rules change, you'll wind up with an unexpected result. (Because the civil time will be different and people usually book appointments based on civil time.)
small_scombrus 2y ago
> They should add an event to detect when someone changes timezones. That sounds like it would be used as yet another data point with which to fingerprint and locate people ._.
- TheAceOfHearts 2y ago
  I don't believe adding this event would represent a new data point for fingerprinting because it's already possible to detect timezone changes by polling `Intl.DateTimeFormat().resolvedOptions().timeZone` and `new Date().getTimezoneOffset()`.
Cthulhu_ 2y ago
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.
crowcroft 2y ago
Since this requires state to track should be up to the developer to define how they want to track and respond to changes in timezone? I'm not sure I would want Temporal to have an opinion on how to handle that?
- TheAceOfHearts 2y ago
  I would expect a timezonechange event to get emitted on the window and that the developer would be responsible for handling it accordingly. This wouldn't require any changes to Temporal.
  - crowcroft 2y ago
    Right, like the browser/app environment would be responsible for it, and then devs can hook into that if they want to handle it or not?
    - TheAceOfHearts 2y ago
      To be clear, the operating system is responsible for keeping track of timezone changes. Every major OS has a way for applications to be notified when the timezone changes. The major browsers are already hooked into these notifications, so what I'm suggesting is that when that event is received by the browser they should also emit a "timezonechange" event on the window. Any further handling is up to the developer.
agos 2y ago
a timezone change event might be a nice idea, but there's no reason it should be inside Temporal

nejsjsjsbsb 2y ago

If you are on a plane or ISS you could even be timezoneless.

jofzar 2y ago
Iss uses Coordinated Universal Time which is just GMT.
dtech 2y ago
I.i.r.c. ISS uses UTC
- noduerme 2y ago
  UTC for the win
esafak 2y ago
Wouldn't you be in the time zone you are traveling over, the same as with other modes of transportation?
- nejsjsjsbsb 2y ago
  You might but that isn't useful. Basically a web app will show you a time affected by your tailwind and weird geopolitics. (The weird politics are not so bad if you stay in the same time zone just changes 2 times a year)

lblume 2y ago

Where would you expect this event to be used? I don't think most web applications somewhat dependent on time should directly have to listen and respond to these events for the amount of people affected by it just doesn't justify the extra effort, I would assume. Libraries could benefit, of course.

TheAceOfHearts 2y ago
To my understanding, it shouldn't require that much effort since browsers should already be keeping track of timezone changes, see Chromium's time_zone_monitor [0]. Browsers could emit a "timezonechange" event on the window. A quick search of gecko-dev shows entries for both WM_TIMECHANGE and NSSystemTimeZoneDidChangeNotification, although they haven't separated it into its own service. I imagine they also track timezone changes for other platforms. [0] https://source.chromium.org/chromium/chromium/src/+/main:services/device/time_zone_monitor/ https://source.chromium.org/chromium/chromium/src/+/main:ser...
scarface_74 2y ago
First JavaScript is unfortunately not just for web apps. It’s also for desktop apps. Say my normal work day is from 8-5 and I work in the Eastern time zone. I set my Slack DND to outside those hours. I hop on a plane and go somewhere on the west coast. The perfect case, Slack would notify me of the change and let me decide whether I wanted to adjust the DND to local time or keep it. There are two possible scenarios for me. I could have flown to Seattle for a business meeting and I want to change my DND to local time to be in sync with the rest of the team onsite. The other scenario is that I’m flying to Los Angeles to hang out. But I’m working during the day and I still need to work east code time.
- klabb3 2y ago
  > First JavaScript is unfortunately not just for web apps. It’s also for desktop apps. A bit of a tangent but I’d say server is bigger than desktop. Like it or not JS (or TS) is the only cross platform development language that’s feasible today if you want to use a single language stack. As much as I despise the JS ecosystem practices and haphazard tooling there is no point trying to put the genie back in the bottle.

noduerme 2y ago

The client's timezone should only matter to the client. There's no condition where their clock matters except to translate a timestamp into their local time (for their convenience). Who cares if they change time zones?

ninkendo 2y ago
So that you can update the UI to show the new time zone? Or change the time format to indicate that it’s no longer in the same time zone as the user is in? That’s just off the top of my head, I’m sure there’s more.
- fkyoureadthedoc 2y ago
  I agree that it would be a nice feature, but I'd really have to be scraping the bottom of the feature barrel before I got to this. Unless my product heavily featured scheduling, or was a clock.
BoppreH 2y ago
Sending emails at specific user times, billing (be careful with this one!), scheduling events in the future, reporting it to other users (Microsoft Teams' "it's 20:39 in this user's Timezone").

aetherspawn 2y ago

Suggestion, design your app to not be time zone dependant if at all possible. For example, store dates in UTC and render instantaneously in current time zone.

mschuster91 2y ago
> and render instantaneously in current time zone And for that you need to have a timezone-change event, if you don't want to poll the current system timezone.
wim 2y ago
That only works for past events, not future ones. Converting to UTC is lossy so rendering timestamps correctly in the future becomes problematic with DST/TZ rule changes.
- lxgr 2y ago
  Really depends on what you want to do. If it's something like "set the date at which new system behavior x becomes effective", UTC is perfectly fine; for scheduling a meeting, not so much.
- sureIy 2y ago
  > Converting to UTC is lossy How so? UTC is a constant point in time. The difficulty lies in representing the value correctly, but the point in time is unchanged. Unlike what sibling comment mentioned, if an appointment is scheduled at 1739287704987, the value will be the same regardless of where and when it's accessed from.
  - burntsushi 2y ago
    Yes, but they're saying that only works for past events. If you book a dentist appointment in the future using a timestamp, but then the tzdb rules change, you'll wind up with an unexpected result. (Because the civil time will be different and people usually book appointments based on civil time.)

small_scombrus 2y ago

> They should add an event to detect when someone changes timezones. That sounds like it would be used as yet another data point with which to fingerprint and locate people ._.

TheAceOfHearts 2y ago
I don't believe adding this event would represent a new data point for fingerprinting because it's already possible to detect timezone changes by polling `Intl.DateTimeFormat().resolvedOptions().timeZone` and `new Date().getTimezoneOffset()`.

Cthulhu_ 2y ago

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.

crowcroft 2y ago

Since this requires state to track should be up to the developer to define how they want to track and respond to changes in timezone? I'm not sure I would want Temporal to have an opinion on how to handle that?

TheAceOfHearts 2y ago
I would expect a timezonechange event to get emitted on the window and that the developer would be responsible for handling it accordingly. This wouldn't require any changes to Temporal.
- crowcroft 2y ago
  Right, like the browser/app environment would be responsible for it, and then devs can hook into that if they want to handle it or not?
  - TheAceOfHearts 2y ago
    To be clear, the operating system is responsible for keeping track of timezone changes. Every major OS has a way for applications to be notified when the timezone changes. The major browsers are already hooked into these notifications, so what I'm suggesting is that when that event is received by the browser they should also emit a "timezonechange" event on the window. Any further handling is up to the developer.

agos 2y ago

a timezone change event might be a nice idea, but there's no reason it should be inside Temporal