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.

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.

> 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.

> 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.