Just to be clear, this is python 2.6, I am using pytz.

This is for an application that only deals with US timezones, I need to be able to anchor a date (today), and get a unix timestamp (epoch time) for 8pm and 11pm in PST only.

This is driving me crazy.

> pacific = pytz.timezone("US/Pacific") > datetime(2011,2,11,20,0,0,0,pacific) datetime.datetime(2011, 2, 11, 20, 0, tzinfo=<DstTzInfo 'US/Pacific' PST-1 day, 16:00:0 STD>) > datetime(2011,2,11,20,0,0,0,pacific).strftime("%s") '1297454400' zsh> date -d '@1297454400' Fri Feb 11 12:00:00 PST 2011 

So, even though I am setting up a timezone, and creating the datetime with that time zone, it is still creating it as UTC and then converting it. This is more of a problem since UTC will be a day ahead when I am trying to do the calculations.

Is there an easy (or at least sensical) way to generate a timestamp for 8pm PST today?

(to be clear, I do understand the value of using UTC in most situations, like database timestamps, or for general storage. This is not one of those situations, I specifically need a timestamp for evening in PST, and UTC should not have to enter into it.)

3

2 Answers

There are at least two issues:

  1. you shouldn't pass a timezone with non-fixed UTC offset such as "US/Pacific" as tzinfo parameter directly. You should use pytz.timezone("US/Pacific").localize() method instead
  2. .strftime('%s') is not portable, it ignores tzinfo, and it always uses the local timezone. Use datetime.timestamp() or its analogs on older Python versions instead.

To make a timezone-aware datetime in the given timezone:

#!/usr/bin/env python from datetime import datetime import pytz # $ pip install pytz tz = pytz.timezone("US/Pacific") aware = tz.localize(datetime(2011, 2, 11, 20), is_dst=None) 

To get POSIX timestamp:

timestamp = (aware - datetime(1970, 1, 1, tzinfo=pytz.utc)).total_seconds() 

(On Python 2.6, see totimestamp() function on how to emulate .total_seconds() method).

Create a tzinfo object utc for the UTC time zone, then try this:

#XXX: WRONG (for any timezone with a non-fixed utc offset), DON'T DO IT datetime(2011,2,11,20,0,0,0,pacific).astimezone(utc).strftime("%s") 

Edit: As pointed out in the comments, putting the timezone into the datetime constructor isn't always robust. The preferred method using the pytz documentation would be:

pacific.localize(datetime(2011,2,11,20,0,0,0)).astimezone(utc).strftime("%s") 

Also note from the comments that strftime("%s") isn't reliable, it ignores the time zone information (even UTC) and assumes the time zone of the system it's running on. It relies on an underlying C library implementation and doesn't work at all on some systems (e.g. Windows).

13

Your Answer

Sign up or log in

Sign up using Google Sign up using Facebook Sign up using Email and Password

Post as a guest

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy