[Python-Dev] Interop between datetime and mxDateTime

[Guido van Rossum]

> [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.

[Tim]
> So you would like to see instead ...?  An exception?

Probably -- None isn't very helpful IMO, but either one is probably
okay.

> 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?

Insofar as that the UTC is unknown in either case, yes.

> >> 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.

Please do, and don't feel constrained by /F's proposal.

--Guido van Rossum (home page: http://www.python.org/~guido/)