[Python-Dev] Status on PEP-431 Timezones

[Lennart Regebro]

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.

But most importantly, there are better ways to solve this that
datetime today doesn't support at all:

1. You can use something like dateutil.rrule for repeating events.
(works today, but requires a third-party module).
2. timedelta could not incorrectly pretend that one day is always 24
hours, but actually handle days separately, and always increase the
days when a day is given. (This would however mean we no longer can
support fractional days).
3. There could be a datetelta() object that makes operations on dates,
leaving hours, minuts, seconds and microseconds alone, or something
like Lubridates Perod and Delta objects, where a Period() essentially
operates on wall time, and a Duration() operates on real time.

So that's not the usecase I'm asking for. I am specifically asking for
a usecase where I want an object that is timezone aware, but ignores
the timezone for everything other than conversion to other timezones.
Because that's what datetime implements. That's what I want a usecase
for. "I want the same time next day" is not such a usecase.

And I don't want that use case for you to convince me that we
shouldn't change datetime. You say it breaks too much. OK, if you say
so. I don't know.
I want to know if that use case actually exists, because I don't think it does.

> But it doesn't matter whether you _call_ them "calendar operations",
> or anything else.  What they're called doesn't change any of the
> high-order bits:  they are use cases, they already work, they have
> worked that way for a dozen years (an eternity in "computer time"),
> they were always intended to work that way, and the docs have always
> said they work that way.

They only work like that because people have adapted to how datetime
does things. If datetime had done this properly from the start, it
would have worked even better.

> I do think you're missing my fundamental objection:  no matter what
> intended and documented thing datetime (or any other module) has done
> all along, and regardless of whether I loved it or hated it, I'd be
> just as annoying about insisting we cannot intentionally break
> existing code

I stopped arguying for changing datetime two days ago. I've also
mentioned that several times.

> using that thing in non-trivial ways without a
> justification so compelling that I can't recall a case of it ever
> happening.

Well, I've seen several of those on Stackoverflow.

//Lennart