[Python-Dev] Status on PEP-431 Timezones

[R. David Murray]

On Wed, 29 Jul 2015 06:26:44 +0200, Lennart Regebro <regebro at gmail.com> wrote:
> On Tue, Jul 28, 2015 at 10:26 PM, Tim Peters <tim.peters at gmail.com> wrote:
> >> I have yet to see a use case for that.
> >
> > Of course you have.  When you address them, you usually dismiss them
> > as "calendar operations" (IIRC).
> 
> Those are not usecases for this broken behaviour.
> 
> I agree there is a usecase for where you want to add one day to an 8am
> datetime, and get 8am the next day. Calling them "date operations" or
> "calendar operations" is not dismissing them. I got into this whole
> mess because I implemented calendars. That use case is the main
> usecase for those operations.
> 
> But that usecase is easily handled in several ways. Already today in
> how datetime works, you have two solutions: The first is to use a time
> zone naive datetime. This is what most people who want to ignore time
> zones should use. The other is to separate the datetime into date and
> time objects and add a day to the date object.

I said I was done commenting, and this is supposed to move to the
datetime-sig, but this "lack of use cases" keeps coming up, so I'm going
to make one more comment, repeating something I said earlier.

What *I* want aware datetimes to do is give me the correct timezone
label when I format them, given the date and time information they hold.
The naive arithmetic is perfect, the conversion between timezones is
fine, the only thing missing from my point of view is a timezone
database such that if I tell a datetime it is in zone X, it will print
the correct offset and/or timezone label when I format it as a string.

That's my use case; and it is, I would venture to guess, *the* most
common use case that datetime does not currently support, and I was very
disappointed to find that pytz didn't support it either (except via
'normalize' calls, but why should I have to call normalize every
time I do datetime arithmetic?  It should just *do* it.)

Anything more would be gravy from my point of view.

Now, maybe tzinfo can't actually support this, but I haven't heard Tim
say that it can't.  Since the datetime is always passed to tzinfo,
I think it can.

--David

PS: annoying story: I scheduled an event six months in advance on my
tablet's calendar, and it scheduled it using what was my *current* GMT
offset (it calls it a time zone) even though it knew what date I was
scheduling it on.  Which meant the alarm in my calendar was off by an
hour.  I hope they have fixed this bug.  I relay this because it is
exactly the same problem I find to be present in pytz.  If the calendar
had been using aware datetimes and naive arithmetic as I describe above,
the alarm would not have been off by an hour.