On Tue, Jun 5, 2012 at 7:19 AM, Dirkjan Ochtman <dirkjan at ochtman.nl> wrote: > On Tue, Jun 5, 2012 at 3:45 PM, Guido van Rossum <guido at python.org> wrote: >> For datetimes with tzinfo, dt.totimestamp() should return (dt - >> epoch).total_seconds() where epoch is >> datetime.datetime.fromtimestamp(0, datetime.timezone.utc); for >> timezones without tzinfo, a similar calculation should be performed >> assuming local time. The utctotimestamp() method should insist that dt >> has no tzinfo and then do a similar calculation again assuming the >> implied UTC timezone. > > It would be nice if utctotimestamp() also worked with datetimes that > have tzinfo set to UTC. Hm, but utcfromtimestamp() never returns a datetime that has a tzinfo (it doesn't take a tzinfo argument like fromtimestamp() does). But if we want to do this, we should just say that utcfromtimestamp() with a datetime that has a tzinfo honors the tzinfo, always. In fact, we might go further and define fromtimestamp() to do the same thing. Then the only difference between the two would be what timezone they use if there is *no* tzinfo. That's fine with me. > And while I don't think we really need it, if there are concerns that > some other epochs may be useful, we could add an optional epoch > argument. No, that's hypergeneralization. People working with other epochs can write the three lines of code -- or they can add or substract a constant that is the difference between *their* epoch and 1/1/1970. Alternate epochs just aren't that common (and where they are, the datetime module probably isn't what you want -- you're probably doing calendrical calculations using some other calendar). -- --Guido van Rossum (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