Dates of past events are always UTC, dates of future physical events must always be a timestamp and a location, dates of future virtual events are either UTC or location based depending on how virtual they actually are.
I can tell you from bitter experience that if you have an event where a person has to arrive at a place at a time and you store that as UTC instead of wall clock, you will have a problem at some point
Yes! All past events have well defined times, even in the face of human silliness like changing timezones and before such ideas existed.
The future is defined by intent which is imprecise (will Oregon drop daylight savings time or not — who knows?). I don’t know how many seconds it is until my next birthday, but I know exactly how many have passed since I was born.
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 timezone available for past events ie. atm withdrawal.
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.
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.
> 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.
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.
I can tell you from bitter experience that if you have an event where a person has to arrive at a place at a time and you store that as UTC instead of wall clock, you will have a problem at some point