4 ms·

Past/future doesn't matter, what matters is context. You don't need to use timezones for ie. setTimeout even though it refers to the future and you should have

• marshmellman 2y ago
  setTimeout takes a duration in ms, not a timestamp. If it did take a timestamp, I think you would need to pass it a timezone to disambiguate. Maybe a better argument is, “when you’re setting a phone alarm, you don’t tell it a timezone.” Maybe the distinction is whether the timezone is established at write time or read time.
  • jitl 2y ago
    Scheduling on a calendar (occur on date X, time Y, in zone Z) and scheduling based on timedelta from instant time (occur exactly X milliseconds before or after instant Y) are both valid, and you can do timedelta scheduling in UTC without needing timezones. The issues come from conflating the two; using timedelta reasoning for calendar scheduling, or using calendar scheduling when you want an exact timedelta.
  • lxgr 2y ago
    > when you’re setting a phone alarm, you don’t tell it a timezone. Which coincidentally and ironically makes phone alarms surprisingly difficult to implement in a way that does not break in the face of DST shifts, timezone changes etc., as Apple has learned the hard way a couple of times.
• Denvercoder9 2y ago
  > Past/future doesn't matter Past/future does matter, as generally speaking it's possible to accurately convert between local time and UTC for times in the past, but not in the future. There's a few exceptions where governments have retroactively changed timezones or DST rules, but at that point you've lost anyway.