On Tue, Jun 5, 2012 at 7:19 AM, Dirkjan Ochtman <dirk...@ochtman.nl> wrote: > On Tue, Jun 5, 2012 at 3:45 PM, Guido van Rossum <gu...@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) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
