[Datetime-SIG] What's are the issues?

[Chris Angelico]

On Wed, Jul 29, 2015 at 12:02 PM, Chris Barker <chris.barker at noaa.gov> wrote:
> On Tue, Jul 28, 2015 at 6:43 PM, Chris Angelico <rosuav at gmail.com> wrote:
>
>> What if the existing timedelta is left as-is, and a new calendardelta
>> type is introduced? Instead of folding everything down to a simple
>> microsecond count, it would retain the exact values it was given,
>
>
> sure -- that would be one way to do it -- maybe  good way. But it would be a
> lot more complicated than just keeping days. Lots to hash out for API and
> functionality at the corner cases (the old what's one year after Feb 29th?
> kinds of questions)

I'd say "one year after Feb 29th" is exactly the same question as "one
day after 2:30AM before a DST switch", and has the same answer (add
another day, or another hour).

>> When you add a
>> calendardelta to an aware datetime, it performs what you're describing
>> as calendar arithmetic,
>
> actually, no reason you couldn't do calendar manipulations on naive
> datetimes, too (they wouldn't get any ugly DST issues, but otherwise the
> same). One reason I don't like calling the arithmetic naive or not....

Yes, but when you do them on naive datetimes, they'll be
indistinguishable from the existing behaviour, and thus not a
compelling argument for a new timedelta variant. I agree though - it
wouldn't be an error to add a calendardelta to a naive datetime.

>> adding
>> calendardelta(days=1) would never affect the hour/minute/second shown,
>> unless it would otherwise create an illegal time.
>
>
> exactly -- all those corner cases would need to be worked out.

Simplest definition would be what we want here. Jump forward by
another unit of whatever one has disappeared. What if we're moving
backward? If you subtract a year from Feb 29th 2012, do you get Feb
28th 2011 or Mar 1st 2011? But I think adding a year should produce
Mar 1st 2013.

ChrisA