5

I've looked all around, and there seem to be a lot of hacks, but no simple, "good" ways to do this. I want to convert a Python datetime object into microtime like time.time() returns (seconds.microseconds).

What's the best way to do this? Using mktime() strips off the microseconds altogether, you could conceivably build up a timedelta, but that doesn't seem right. You could also use a float(strftime("%s.%f")) (accounting for rounding seconds properly), but that seems like a super-hack.

What's the "right" way to do this?

agf
  • 171,228
  • 44
  • 289
  • 238
Taj Morton
  • 1,588
  • 4
  • 18
  • 26

3 Answers3

8
time.mktime(dt.timetuple()) + dt.microsecond / 1000000.0 

works if you don't want to use strftime and float.

It returns the same thing as time.time() with dt = datetime.datetime.now().

agf
  • 171,228
  • 44
  • 289
  • 238
  • If the timezone for datetime object and your local timezone may not be the same, you should use calendar.gmtime(dt.utctimetuple()) instead – Ryan Ye Aug 30 '11 at 03:59
  • I think you mean `calendar.timegm`, and that gives the same answer as Mark's version -- meaning it's incorrect for non-UTC `datetime` objects. The time since the epoch for me is the same as for someone in UTC, not different by my UTC offset. – agf Aug 30 '11 at 04:09
  • It's always correct regardless of your timezone, since dt.utctimetuple returns time tuple of the datetime object in UTC. And calendar.timegm takes a utc timetuple. – Ryan Ye Aug 30 '11 at 05:20
  • Did you try it? `time.time()` and `calendar.timegm(datetime.datetime.now().utctimetuple())` don't give the same time since the epoch for non-UTC timezones, while the same amount of time has passed since the epoch no matter what time zone you're talking about, since the epoch was UTC and `time.time()` returns time in UTC. – agf Aug 30 '11 at 05:22
  • I see. I'm using calendar.timegm on my website. It works perfectly because my datetime object carries tzinfo. And it seems the datetime object returned by datetime.datetime.now() doesn't contain tzinfo, thus utctimetuple doesn't return the correct result (in lack of tzinfo, utctimetuple returns the same result as timetuple) – Ryan Ye Aug 30 '11 at 05:31
  • So it sounds like your version works for timezone-aware objects or UTC, Mark's works for UTC, mine works for local timezone objects. If you post yours as an answer, I'll upvote it. – agf Aug 30 '11 at 05:34
2
def microtime(dt):
    unixtime = dt - datetime.datetime(1970, 1, 1)
    return unixtime.days*24*60*60 + unixtime.seconds + unixtime.microseconds/1000000.0
Mark Ransom
  • 299,747
  • 42
  • 398
  • 622
  • This doesn't give me the same as `time.time()` for `datetime.datetime.now()`. Looks like you're assuming `dt` is UTC, so you'll be off by the timezone's UTC-offset. – agf Aug 30 '11 at 03:25
  • @agf, what is `time.time()`? I can't find it in the documentation: http://docs.python.org/library/datetime.html – Mark Ransom Aug 30 '11 at 03:26
  • Not `datetime.time`, `time.time()` -- http://docs.python.org/library/time.html#time.time – agf Aug 30 '11 at 03:27
  • @agf: so much for "There should be one-- and preferably only one --obvious way to do it." I never knew about `time` before. And you're correct, my solution assumes you're passing a UTC datetime. – Mark Ransom Aug 30 '11 at 03:30
  • /agree, `datetime` / `time` / `calendar` is a mess. – agf Aug 30 '11 at 03:31
  • 1
    I agree it is a mess. I wrote my own functions to deal with it when I wrote PyFeed. http://home.avvanta.com/~steveha/pyfeed.html – steveha Aug 30 '11 at 03:38
-1

import time;

microtime=int(time.time()*1000);

print microtime;