On Wed, Sep 23, 2015 at 3:13 AM, Alexander Belopolsky <[email protected]> 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. _______________________________________________ Datetime-SIG mailing list [email protected] https://mail.python.org/mailman/listinfo/datetime-sig The PSF Code of Conduct applies to this mailing list: https://www.python.org/psf/codeofconduct/
