[Python-Dev] Interop between datetime and mxDateTime

[Tim Peters]

[Guido]
>>> (Hm, I just found that utctimetuple() returns the same as timetuple()
>>> when the tzinfo is None

[Tim]
>> Yes.  Also if d.tzinfo is not None but d.tzinfo.utcoffset(d)
>> returns 0 or None.

>>> -- that doesn't seem right.)

>> Because ...?

[Guido]
> Because if utcoffset() returns None it's misleading to pretend to be
> able to return a UTC tuple.

So you would like to see instead ...?  An exception?

You didn't mention the utcoffset() is None case at the start, just the
tzinfo is None case.  Do you view those as being the same thing in the end?

>> I'd rather get rid of utctimetuple(), supply a datetime.utc
>> tzinfo subclass out of the box, and change the spelling of
>>
>>     d.utctimetuple()
>>
>> to
>>
>>     d.timetuple(tzinfo=utc)
>>
>> Similarly for datetime.now() vs datetime.utcnow().  The proliferation
>> of ABCutcXYZ methods is confusing, especially since they return
>> naive objects.

> Tell you what.  I sincerely doubt that we'll be able to agree on
> useful semantics for the common base API.  /F's proposal doesn't map
> well on datetime, and that pretty much kills the idea.

I tend to agree, but the comments about

    timetuple() vs utctimetuple()
    now() vs utcnow()
    fromtimestamp() vs utcfromtimestamp()

are about the current datetime API, not really related to /F's proposal.
Since datetime and datetimetz objects are no longer distinct, all spellings
of timetuple(), now() and fromtimestamp() have an optional tzinfo argument
now.  This seems to me to make the 3 additional utc spellings of these
methods at least extravagant.  The semantics of these things are all wrong
anyway (as in the SF bug report about this).  I'd like to simplify this.