In general, to make a naive datetime timezone-aware, use the localize method: import datetime import pytz unaware = datetime.datetime(2011, 8, 15, 8, 15, 12, 0) aware = datetime.datetime(2011, 8, 15, 8, 15, 12, 0, pytz.UTC) now_aware = pytz.utc.localize(unaware) assert aware == now_aware For the UTC timezone, it is not really necessary to use localize since … Read more
The documentation http://pytz.sourceforge.net/ states “Unfortunately using the tzinfo argument of the standard datetime constructors ‘does not work’ with pytz for many timezones.” The code: t = datetime( 2013, 5, 11, hour=11, minute=0, tzinfo=pytz.timezone(‘Europe/Warsaw’) ) doesn’t work according to this, instead you should use the localize method: t = pytz.timezone(‘Europe/Warsaw’).localize( datetime(2013, 5, 11, hour=11, minute=0))
This error occurs when installing pytz using pip v1.4 or newer, due to this change in behaviour: Pre-release Versions Starting with v1.4, pip will only install stable versions as specified by PEP426 by default. If a version cannot be parsed as a compliant PEP426 version then it is assumed to be a pre-release. If a … Read more
I think I got it: pytz.utc.localize(utc_time, is_dst=None).astimezone(tz) This line first converts the naive (time zone unaware) utc_time datetime object to a datetime object that contains a timezone (UTC). Then it uses the astimezone function to adjust the time according to the requested time zone.
In general, to make a naive datetime timezone-aware, use the localize method: import datetime import pytz unaware = datetime.datetime(2011, 8, 15, 8, 15, 12, 0) aware = datetime.datetime(2011, 8, 15, 8, 15, 12, 0, pytz.UTC) now_aware = pytz.utc.localize(unaware) assert aware == now_aware For the UTC timezone, it is not really necessary to use localize since … Read more
Answer based on the answer by Carl Meyer in Google Groups Answer The reason for this difference, is that this is NOT the right way of converting a timezone agnostic datetime object to a timezone aware object. The explanation being: “A pytz timezone class does not represent a single offset from UTC, it represents a … Read more
What I got is just a workaround, the simple rule is Never create datetime with timezone info by using datetime(). This sample would give you a hint for this. As you see, you could avoid the unexpected difference, once and only you make “naive” datetime (it is, datetime without timezone info) and then localize it … Read more
Use tz.localize(d) to localize the instance. From the documentation: The first is to use the localize() method provided by the pytz library. This is used to localize a naive datetime (datetime with no timezone information): >>> loc_dt = eastern.localize(datetime(2002, 10, 27, 6, 0, 0)) >>> print(loc_dt.strftime(fmt)) 2002-10-27 06:00:00 EST-0500 If you don’t use tz.localize(), but … Read more
I assume you have these questions: why does the first function work for UTC timezone? why does it fail for ‘US/Eastern’ timezone (DstTzInfo instance)? why does the second function work for all provided examples? The first function is incorrect because it uses d.replace(tzinfo=dsttzinfo_instance) instead of dsttzinfo_instance.localize(d) . The second function is correct most of the … Read more
See: http://bytes.com/topic/python/answers/676275-pytz-giving-incorrect-offset-timezone In the comments, someone proposes to use tzinfo.localize() instead of the datetime constructor, which does the trick. >>> tz = timezone(‘Asia/Kolkata’) >>> dt = tz.localize(datetime.datetime(2011, 6, 20, 0, 0, 0, 0)) >>> dt datetime.datetime(2011, 6, 20, 0, 0, tzinfo=<DstTzInfo ‘Asia/Kolkata’ IST+5:30:00 STD>) UPDATE: Actually, the official pytz website states that you should always … Read more