Take the 2-minute tour ×

I retrieve a unix timestamp from a web service in a Python program. This timestamp is in a USA timezone. In order to insert it in a MySQL database with other objects, localized in France, I would like to convert this timestamp to the French timezone.

I could do it with mathematical functions, but there is the issue of daylight savings time. I would prefer to use Python time and date specific functions which should deal with these concepts.

Do you have a hint, I am lost in the Python documentation?

share|improve this question
what does zero correspond to ? 00:00:00 1st January 1970 PST or 01:00:00 1st January 1970 PST ? –  Andre Holzner Jul 15 '11 at 12:56
Good question, I am crashing my head against the wall for 3 hours... In fact it seams that it is not PST but PDT. I have an extra-hour (which lead me to -7h instead of - 8H) but in France we are UTC+2H in summer and +1H in winter. I cannot figure it out with mathematical functions. I would probably require pytz –  kheraud Jul 15 '11 at 14:22
My question was not accurate, I missed the problem origin. I open another thread –  kheraud Jul 15 '11 at 14:45

3 Answers 3

up vote 3 down vote accepted

I had a similar problem in the past when the timestamps of the files we downloaded from a service provider had timestamps corresponding to the PST time zone. The following helped me do to the conversion:

import pytz, datetime, time
import os

originalTimeStamp = os.stat("/tmp/file-from-us-west-coast").st_mtime

# prints e.g. 2010-03-31 13:01:18
print "original:",datetime.datetime.fromtimestamp(originalTimeStamp)

# re-interpret 
originalTimeZone = "America/Los_Angeles"
targetTimeZone   = "Europe/Paris"

newTimeStamp = pytz.timezone(originalTimeZone).localize(datetime.datetime.fromtimestamp(originalTimeStamp)).astimezone(pytz.timezone(targetTimeZone))

# prints e.g. 2010-03-31 22:01:18+02:00
print "new:     ",newTimeStamp

# convert back to seconds since epoch
newTimeStamp = time.mktime(newTimeStamp.timetuple())

# print time difference in hours
print (newTimeStamp - originalTimeStamp) / 3600.0
share|improve this answer
Even if my question was badly explained (I didn't find the exact problem yet), you solved it :) –  kheraud Jul 15 '11 at 15:33
if you can test arbitrary dates, as an ultimate test I'd suggest to test what happens with 3rd November 2011. Europe will have winter time while the U.S. still has daylight saving time (see e.g. worldtimezone.com/daylight.html ) –  Andre Holzner Jul 15 '11 at 16:05

If it's really a unix timestamp, then it's UTC based. Just interpret it correctly for your use case. Apply the timezone translation only when you have to print this date as text.

If you're storing it as timestamp on your side too, keep it exactly as it is.

share|improve this answer
It's not a "unix timestamp" but the number of seconds elapsed from January 1, 1970 based on the ouest pacific timezone. It's ugly, I know, but it's Facebook API. I can't keep it as it is because I have other objects based on real "unix timestamp" : UTC –  kheraud Jul 15 '11 at 12:35
If you know it's pacific time and not changing, you can just add the 8 hours to make it UTC and use as a unix timestamp. –  viraptor Jul 15 '11 at 12:50
In fact Facebook api doesn't take into account that France is GMT+2 in summer and GMT+1 in spring. All is stored in DB as the filled date but on the Pacific Standard Timezone. For example I create an event 2011-07-15 23:00 on facebook site. It is stored as 2011-07-15 23:00-0000 (PST). All the problem comes from here. pytz solved the problem –  kheraud Jul 15 '11 at 15:53

pytz might help you out here. Like viraptor said, ideally you'd store all your datetimes as unix UTC timestamps, and only localize the time when you print it out.

share|improve this answer

Your Answer


