Can Walter stop living in the future? (meta)

[Nick Sabalausky (Abscissa)]

On 5/16/19 3:24 PM, Johannes Loher wrote:
> On Thursday, 16 May 2019 at 16:46:13 UTC, H. S. Teoh wrote:
>>
>> Seriously, everyone should just store (and transmit) all dates in UTC 
>> always. Let the software format it according to the local timezone 
>> when it needs to be displayed.  Then there would be no problems.
> 
> Unfortunately, this is actually not sufficient for all use cases. Not 
> all dates are points in time, while dates in UTC are. E.g changes to 
> timezones happen more often than you‘d expect. What if you set your 
> alarm to 7:00 AM in a given timezone and then the timezone is adjusted 
> to one hour earlier. Do you want to go your alarm to go off at 8:00 AM 
> in that timezone now, which would be what you‘d get if the time was 
> stored in UTC? Probably not, you want it to still go off at 7:00 AM in 
> that timezone. Handling dates and time can be unexpectedly more 
> difficult than one believes at first.

Fair point. My analysis of this:

"UTC vs Local Time" is basically "absolute vs relative". UTC is a 
specific, unambiguous, point in time, period. Local time is UTC viewed 
through a chosen filter (and it's a filter that's not necessarily 1:1 
(example: daylight savings time), which makes things extra fun).

So the choice of "UTC vs Local" is analogous to filesystem paths 
(absolute vs relative paths). Accordingly, the question should be "Am I 
referring to a very specific, unambiguous point in time? Or am I 
referring to a local perspective of time?" Much like HSTeoh, I strongly 
suspect the vast majority of cases should be absolute time (ie, UTC, 
with local time being treated as a presentation-layer detail).

But you bring up the idea of a user setting an alarm...and that raises 
an interesting wrinkle...As I see it, the problem here stems from the 
fact that there are potentially *TWO* different perspectives (ie "time 
zones") involved: (keeping in mind that "time zone" can also refer to 
daylight-savings status)

Perspective A: The time zone (or daylight-savings status) of the user 
when they set the alarm.

Perspective B: The time zone (or daylight-savings status) of the user 
when the alarm sounds.

(Note that this is NOT an "absolute vs relative" distinction, but a 
distinction between two different relative perspectives: Kind of like 
"~" vs "." in filepaths.)

Since all user-input involving time should naturally be considered to be 
relative to the user's own perspective (unless the user specifically 
states otherwise), this creates a dilemma because there are *two* user 
perspectives: Is the user entering a time relative to their current 
perspective ("time zone") of time? (Ie, "A"). Or are they entering a 
time relative to their own future self *at the moment of the alarm*? 
(ie, "B").

To be perfectly honest, I think any "set alarm" interface that doesn't 
clarify this "time-when-setting-alarm vs time-when-sounding-alarm" 
distinction is an inherently ambiguous interface from the user's 
perspective (not that most users are likely to notice this ambiguity 
unless its pointed out). So I agree this is a difficult situation to 
solve...*however*...I think it's difficult to solve *because* of 
competing perspectives (ie, competing local time zones and/or competing 
local daylight savings statuses), and NOT because of absolute ("UTC") vs 
relative ("local" time...but *which* local time, "upon-setting" or 
"upon-activation"?).

Ultimately, the software (combined with its communication to the user) 
has to make a choice as to which user perspective the alarm's time is 
relative to: The user when setting the alarm, or the user when receiving 
the alarm.

In any case, if the user's (admittedly unlikely) desire is unambiguously 
A: "use the user's perspective when setting the alarm", then I'll admit 
that despite being unlikely, the user in this case clearly *wants* to be 
woken at *local* 8 o'clock in your example (ie, "Activate the alarm at 
the point that will be 7 o'clock in the time zone I'm in right now while 
I'm setting the alarm"). So the time they enter should immediately be 
converted to UTC and stored as UTC so that later on, any current "now" 
local time can be converted to UTC and compared with the absolute 
desired point in time to determine if sounding an alarm is warranted.

On the other hand, in the (more likely) case the user's desire is 
unambiguously B: "use the user's perspective when they are BEING 
AWAKENED by the alarm", then obviously it is impossible to predict the 
user's future time zone. Therefore, a UTC CANNOT be chosen 
ahead-of-time. So when the user sets the alarm, the software must store 
the alarm's time NOT as an unambiguous UTC, but as a time that's 
*relative* to whatever selected timezone (or daylight-savings status) 
may be "active" when the alarm is sounded. This means storing just 
simply a local (ie, relative, non-UTC) time and then later, upon 
checking whether the alarm should be sounded...converting the UTC of 
*now* to the time zone the user is in, and comparing *that* to the 
relative time ("7am"?) stored as the alarm trigger.