> [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 ...? Because if utcoffset() returns None it's misleading to pretend to be able to return a UTC tuple. > 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. --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4