[Datetime-SIG] Computing .dst() as a timedelta

[Chris Angelico]

On Wed, Sep 23, 2015 at 3:13 AM, Alexander Belopolsky
<alexander.belopolsky at gmail.com> wrote:
> I call UTC "make it equally annoying to everyone choice."   It is tolerable
> within (Western) Europe, but when your team is more geographically diverse,
> 2AM UTC may still be Saturday for some.

It may indeed - that's actually a feature (most of our American
players like it being a Saturday evening).

> Our job as programmers is to teach computers how to understand humans, not
> the other way around.  A good scheduling application should allow you to set
> up the schedule in any way you want including your local time, your standard
> time or any other time zone that is "special" for your particular case
> (Dragonlance Mean Time, perhaps:-).  Once scheduled, the times should be
> displayed to your team members in their local time.  If you make a schedule
> relative to a time zone with DST transitions, some of your team members may
> be surprised by the apparent changes of the schedule.  That's a human
> problem - whatever compromise you come up with - your computer should be
> helpful in implementing.

The trouble is the exact same thing that we were discussing with the
beginning of this mailing list. Allow me to spin you a few scenarios.

"Hi folks! We're starting a D&D campaign, and we'll be meeting up every week."
1) "It'll be at 9PM every Saturday in your time zone (Chicago)." --
different for everyone
2) "It'll be at noon every Sunday for the Dungeon Master (Melbourne)."
3) "It'll be at 2AM every Sunday in UTC."

I can easily write a program that does the conversions - in fact, I
have one built into the MUD client that we use for actually playing
the game. The trouble is, people will expect these recurring events to
repeat on a cycle based on the displayed time - what's been referred
to as "classic" or "naive" arithmetic. The result is:

1) Game time is every Saturday when my clock shows 9PM.
2) Game time is ... uhh ... I dunno, I'll just show up some time and hope.
3) Game time is 168 hours after the previous game started.

#1 fundamentally can't work, because we have to sync up around the
globe. Either that, or the program has to recalculate "it'll be 9PM
this week, but 8PM next week" every time, and it would have to do that
on the basis of #2 or #3. Even so, it's confusing to have to go and
check it every time; the clock time for the game might change
unpredictably, depending on the fundamental timezone.

#2 inflicts double DST confusion on everyone that isn't in the same
time zone as the Dungeon Master. This is how Threshold RPG works - the
official timezone is EST (though I prefer to describe it by its tzdata
name, America/New_York), so anyone in the US east coast states has it
easy, and other people in contiguous USA are doing reasonably alright;
folks in Australia [1] have to cope with two hour DST changes each
year, and folks in Europe have to worry about temporary
desynchronizations each year as DST stabilizes.

#3 works for everyone. Again, papering over the difference slightly
can help (which is why the MUD client has a time converter in it), but
it's much easier to explain: when you go onto Daylight Saving Time,
your clock moves forward, which means the next session will happen at
9PM on your clock instead of 8PM. There's exactly one clock shift for
every DST transition, and all you have to do is explain to people that
DST doesn't change anything except your clock. That's why we schedule
things in UTC.

Showing the time in your local timezone as an abstraction over a UTC
fundamental is nice and safe. We *know* we can always do that
unambiguously, and it's easy to explain what's going on. It's still a
leaky abstraction, though, and I prefer to explicitly tell people that
it's scheduled in UTC, but that they can see what UTC time translates
to what local time. That's why it's safest to be clear about UTC
usage, and honestly, this has nothing to do with what a computer can
and can't be taught to do - it's all about what humans can get their
heads around.

ChrisA

[1] Except Queensland, where they're smart.