Mailman 3 September 2015 - Datetime-SIG

Re: [Datetime-SIG] Computing .dst() as a timedelta
by Alexander Belopolsky Sept. 22, 2015

Sept. 22, 2015

On Tue, Sep 22, 2015 at 1:40 PM, Chris Angelico <rosuav(a)gmail.com> wrote: > > 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. UTC is no better than DMT (Dragonlance Mean Time). In fact, I think I will have easier time explaining DMT to a ten year old than explaining UTC. If your team can agree on a natural language, they can agree on a timescale. It does not matter what it is. If uniformity was a universal virtue, we would all be speaking Esperanto by now.

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by Chris Angelico Sept. 22, 2015

Sept. 22, 2015

On Wed, Sep 23, 2015 at 3:13 AM, Alexander Belopolsky <alexander.belopolsky(a)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.

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by Alexander Belopolsky Sept. 22, 2015

Sept. 22, 2015

On Tue, Sep 22, 2015 at 12:44 PM, Chris Angelico <rosuav(a)gmail.com> wrote: > > Yes! Yes, a hundred times yes! Whenever possible, I try to synchronize > on UTC with everyone. Our Dungeons & Dragons campaigns are all > scheduled that way - eg I run one at 2AM UTC every Sunday. It's fair > on everyone, that way; nobody has to cope with more than one > timezone's DST changes, and only ever their own. 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. 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.

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by M.-A. Lemburg Sept. 22, 2015

Sept. 22, 2015

On 21.09.2015 18:20, Alexander Belopolsky wrote: > On Mon, Sep 21, 2015 at 11:49 AM, M.-A. Lemburg <mal(a)egenix.com> wrote: >> >> Looks like assigning a "time zone" to the place is simply conceptually >> wrong and was just done to make some tz folks happy. > > > Yes, the best definition of "time zone" in computing contexts is the one > given by the tzdist group: "A description of the past and predicted future > timekeeping practices of a collection of clocks that are intended to > agree." Apparently, there is no concerted effort at the Troll station to > have a station-specific set of timekeeping rules. They just use either UTC > or Europe/Oslo depending on the needs of the current expedition. Ah, the joys of freedom of choice :-) >> Anyway, the main takeaway for me is that it is obviously possible >> to have more than two DST switches during the year, which is >> something I wasn't aware of before seeing this example. > > The March 1st switch at Troll from UTC to CET is not really a DST > transition. It is a transition that changes the standard time. (The value > of isdst does not change in the transition.) > > Even more exotic things can happen if one would try to model a ship's clock > using a tzinfo instance. By convention, ships use the time of the closest > port or whatever the captain feels appropriate in international waters. > Since ship logs are usually reliable and ship speed is low, such specialty > application will probably work in most cases. Note that faster vehicles > such as the ISS use UTC these days, but I think the Apollo program used the > Houston time. Time on ships seems to depend on what the captain and company think is the right way: http://travel.stackexchange.com/questions/43245/what-time-is-used-on-board-… even though there is a standard called "Nautical time" for this: https://en.wikipedia.org/wiki/Nautical_time """ In practice, nautical times are used only for radio communication, etc. Aboard the ship, e.g. for scheduling work and meal times, the ship may use a suitable time of its own choosing. The captain is permitted to change his or her clocks at a chosen time following the ship's entry into another time zone, typically at midnight. Ships on long-distance passages change time zone on board in this fashion. On short passages the captain may not adjust clocks at all, even if they pass through different time zones, for example between the UK and continental Europe. Passenger ships often use both nautical and on-board time zones on signs. When referring to time tables and when communicating with land, the land time zone must be employed. """ On planes, the situation seems to be similar. I've not been on a flight yet where the captain announces new time zones midway :-) I guess even though the approach to use location names for time zones creates a more or less sane system on the ground, it doesn't really address the changes in authority when things start moving. Perhaps we should just standardize on UTC world-wide and then instead have the work day begin at different times depending on location. Crazy idea, but then it'd safe us all a lot of work :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Sep 22 2015) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ 2015-09-14: Released mxODBC Plone/Zope DA 2.2.3 http://egenix.com/go84 2015-09-26: Python Meeting Duesseldorf Sprint 2015 4 days to go 2015-10-21: Python Meeting Duesseldorf ... 29 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

3 2

Re: [Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement
by Guido van Rossum Sept. 21, 2015

Sept. 21, 2015

On Sun, Sep 20, 2015 at 8:49 PM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > On Sat, Aug 15, 2015 at 8:49 PM, Alexander Belopolsky < > alexander.belopolsky(a)gmail.com> wrote: > > > > PEP 495 [1] is a deliberately minimalistic proposal to remove an > > ambiguity in representing some local times as datetime.datetime > > objects. > > A major issue has come up since my announcement above. Tim Peters have > noticed that PEP 495 would violate the "hash invariant" unless the fold > attribute is accounted for in inter-zone comparisons. > See [2] for details. This issue has been resolved by modifying the > definition [3] of the "==" operator for aware datetimes with post-PEP > tzinfo. Note that no program will be affected by this change unless it > uses a post-PEP tzinfo implementation. > > I made some smaller changes [4] to the PEP as well and it should finally > be ready for pronouncement. > > [1]: https://www.python.org/dev/peps/pep-0495 > [2]: > https://mail.python.org/pipermail/datetime-sig/2015-September/000625.html > [3]: > https://www.python.org/dev/peps/pep-0495/#aware-datetime-equality-comparison > [4]: https://hg.python.org/peps/log/39b7c1da05a2/pep-0495.txt > I've reviewed this latest version and I am hereby accepting it. The topic is both controversial and yawn-inducing, so I think it's better not to give the usual one-day warning on python-dev -- I'll just post my decision there. Alexander and Tim, thank for all your work on this! It's been a wild, wild ride. (And no, I am not going to make a joke about leap seconds here. :-) -- --Guido van Rossum (python.org/~guido)

1 0

Re: [Datetime-SIG] PEP 495 (Local Time Disambiguation) is ready for pronouncement
by Alexander Belopolsky Sept. 21, 2015

Sept. 21, 2015

For those who prefer using Github's review tools, I have republished the PEP at <https://github.com/abalkin/ltdf/tree/pep-0495>. Comments and pull requests are welcome. On Sun, Sep 20, 2015 at 11:49 PM, Alexander Belopolsky < alexander.belopolsky(a)gmail.com> wrote: > On Sat, Aug 15, 2015 at 8:49 PM, Alexander Belopolsky < > alexander.belopolsky(a)gmail.com> wrote: > > > > PEP 495 [1] is a deliberately minimalistic proposal to remove an > > ambiguity in representing some local times as datetime.datetime > > objects. > > A major issue has come up since my announcement above. Tim Peters have > noticed that PEP 495 would violate the "hash invariant" unless the fold > attribute is accounted for in inter-zone comparisons. > See [2] for details. This issue has been resolved by modifying the > definition [3] of the "==" operator for aware datetimes with post-PEP > tzinfo. Note that no program will be affected by this change unless it > uses a post-PEP tzinfo implementation. > > I made some smaller changes [4] to the PEP as well and it should finally > be ready for pronouncement. > > [1]: https://www.python.org/dev/peps/pep-0495 > [2]: > https://mail.python.org/pipermail/datetime-sig/2015-September/000625.html > [3]: > https://www.python.org/dev/peps/pep-0495/#aware-datetime-equality-comparison > [4]: https://hg.python.org/peps/log/39b7c1da05a2/pep-0495.txt >

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by Alexander Belopolsky Sept. 21, 2015

Sept. 21, 2015

On Mon, Sep 21, 2015 at 1:02 PM, Chris Angelico <rosuav(a)gmail.com> wrote: > On Tue, Sep 22, 2015 at 2:20 AM, Alexander Belopolsky > <alexander.belopolsky(a)gmail.com> wrote: > > Note that faster vehicles such as the ISS use UTC these days... > > Isn't the ISS fast enough that relativity starts getting in the way? > Not fast enough for an astronaut to miss a wedding anniversary. I am *so* glad the Python datetime module doesn't have to concern itself > with that... > Neither do the astronauts when they schedule a video conference with a family at home and that's the only time they need to worry about civil time zones on the Earth.

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by Chris Angelico Sept. 21, 2015

Sept. 21, 2015

On Tue, Sep 22, 2015 at 2:20 AM, Alexander Belopolsky <alexander.belopolsky(a)gmail.com> wrote: > Note that faster vehicles such as the ISS use UTC these days... Isn't the ISS fast enough that relativity starts getting in the way? I am *so* glad the Python datetime module doesn't have to concern itself with that... ChrisA

1 0

Re: [Datetime-SIG] Computing .dst() as a timedelta
by M.-A. Lemburg Sept. 21, 2015

Sept. 21, 2015

On 21.09.2015 17:01, Alexander Belopolsky wrote: > On Mon, Sep 21, 2015 at 8:44 AM, M.-A. Lemburg <mal(a)egenix.com> wrote: > >> Interesting. It lists two "DST"s per year: they first >> go from GMT to CET, then to CEST, and then back to CET and GMT. >> I guess they switched to CET when the station was used and >> to GMT for the instruments during winter when it was not used. >> >> But this is not consistent with what the Norwegians report on their >> Troll station website: >> >> http://www.npolar.no/en/about-us/stations-vessels/troll/index.html >> >> """ >> The time zone Troll is located in, UTC +0, is 1 hour behind Norwegian >> time (2 hours during summer time in Norway). Photo: Norwegian Polar >> Institute >> """ >> >> The webcam confirms this: >> ftp://ftp.npolar.no/Out/TrollWebCam/TrollPublic.jpg >> > > For those who care about this kind of timezone trivia, apparently [1] Troll > station is inhabited by Norwegians only during the colder months > (March–October) > who use Norwegian time (TZ=Europe/Oslo). During the warmer ("busy") > season, the station switches to UTC as an option that is equally annoying > to all international inhabitants. > > The specific rules that appear in some versions of the IANA zone info files > are pure fantasy. > > [1]: http://mm.icann.org/pipermail/tz/2014-March/020705.html Looks like assigning a "time zone" to the place is simply conceptually wrong and was just done to make some tz folks happy. Anyway, the main takeaway for me is that it is obviously possible to have more than two DST switches during the year, which is something I wasn't aware of before seeing this example. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Sep 21 2015) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ 2015-09-14: Released mxODBC Plone/Zope DA 2.2.3 http://egenix.com/go84 2015-09-26: Python Meeting Duesseldorf Sprint 2015 5 days to go 2015-10-21: Python Meeting Duesseldorf ... 30 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

3 2

Re: [Datetime-SIG] Computing .dst() as a timedelta
by M.-A. Lemburg Sept. 21, 2015

Sept. 21, 2015

On 20.09.2015 02:30, Tim Peters wrote: > [Alex] >> Tim, are you referring to the "Troll" rule? [1] That's a strange beast >> indeed and a comment above it says: >> >> # The CET-switching Troll rules require zic from tzcode 2014b or later, so >> as >> # suggested by Bengt-Inge Larsson comment them out for now, and approximate >> # with only UTC and CEST. Uncomment them when 2014b is more prevalent. > > Yes, and this was pointed out some time ago. These really are the > rules they use: > > http://www.timeanddate.com/time/zone/antarctica/troll Interesting. It lists two "DST"s per year: they first go from GMT to CET, then to CEST, and then back to CET and GMT. I guess they switched to CET when the station was used and to GMT for the instruments during winter when it was not used. But this is not consistent with what the Norwegians report on their Troll station website: http://www.npolar.no/en/about-us/stations-vessels/troll/index.html """ The time zone Troll is located in, UTC +0, is 1 hour behind Norwegian time (2 hours during summer time in Norway). Photo: Norwegian Polar Institute """ The webcam confirms this: ftp://ftp.npolar.no/Out/TrollWebCam/TrollPublic.jpg -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Sep 21 2015) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ________________________________________________________________________ 2015-09-14: Released mxODBC Plone/Zope DA 2.2.3 http://egenix.com/go84 2015-09-26: Python Meeting Duesseldorf Sprint 2015 5 days to go 2015-10-21: Python Meeting Duesseldorf ... 30 days to go eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/

2 1