[Python-Dev] Status on PEP-431 Timezones

[Tim Peters]

[Lennart Regebro]
\>>> I have yet to see a use case for that.

[Tim]
>> Of course you have.  When you address them, you usually dismiss them
>> as "calendar operations" (IIRC).

'[Lennart]

> 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