«

Hi All,

Using pytz, I am facing a problem with Asia/Calcutta, described below.

Asia/Calcutta is actually IST, which is GMT + 5:30. But while using
pytz, it was recognized as HMT (GMT + 5:53). While I digged into the
oslan database, I see the following:

# Zone NAME GMTOFF RULES FORMAT [UNTIL]
Zone Asia/Calcutta 5:53:28 - LMT 1880 # Kolkata
5:53:20 - HMT 1941 Oct # Howrah Mean Time?
6:30 - BURT 1942 May 15 # Burma Time
5:30 - IST 1942 Sep
5:30 1:00 IST 1945 Oct 15
5:30 - IST

Searching in this group, I saw a similar problem posted at
http://groups.google.co.in/group/com...496e85797ac890
without any solutions.

I mailed to Stuart and also posted it at the launchpad of pytz, but
did not get any response.

Unable to know how to proceed further. Any suggestion will be of vital
help.

thanks
Sanjay

On Jul 12, 11:47 am, Sanjay <skpate...@gmail.com> wrote:
> Hi All,
>
> Using pytz, I am facing a problem with Asia/Calcutta, described below.
>
> Asia/Calcutta is actually IST, which is GMT + 5:30. But while using
> pytz, it was recognized as HMT (GMT + 5:53). While I digged into the
> oslan database, I see the following:
>
> # Zone NAME GMTOFF RULES FORMAT [UNTIL]
> Zone Asia/Calcutta 5:53:28 - LMT 1880 # Kolkata
> 5:53:20 - HMT 1941 Oct # Howrah Mean Time?
> 6:30 - BURT 1942 May 15 # Burma Time
> 5:30 - IST 1942 Sep
> 5:30 1:00 IST 1945 Oct 15
> 5:30 - IST
>
> Searching in this group, I saw a similar problem posted athttp://groups.google.co.in/group/comp.lang.python/browse_thread/threa...
> without any solutions.
>
> I mailed to Stuart and also posted it at the launchpad of pytz, but
> did not get any response.
>
> Unable to know how to proceed further. Any suggestion will be of vital
> help.
>
> thanks
> Sanjay

I don't use pytz myself that often so I can't be sure, but I don't
think it's a bug in pytz.

The problem seems to be that the timezone has changed for the
location. Now, without a date as reference, pytz can't know what
timezone to use when constructing the tzinfo; you might want a date
from the 1800's.

When you're constructing the datetime with the tzinfo argument, you're
saying: use this timezone as the local timezone. datetime_new (the
constructor in C) never calls the tzinfo to verify that the timezone
is still valid, it just uses it.

On the other hand: When you construct a datetime with datetime.now()
and pass a timezone, datetime_now (again, in C) calls the method
fromutz() on the tzinfo object. Now the pytz tzinfo object has a
reference by which to choose the current timezone for the location,
and that's why it's correct when you use datetime.now() but not for a
manual construction.

A "workaround" (or maybe the proper way to do it) is to construct the
datetime without a tzinfo set, and then use the localize() method on
the tzinfo object, this will give you the correct result.

>>> tz = pytz.timezone("Asia/Calcutta")
>>> mydate = datetime.datetime(2007, 2, 18, 15, 35)
>>> print tz.localize(mydate)
2007-02-18 15:35:00+05:30

Hi Simon,

localize worked perfectly. Thanks a lot for the vital help! Your
elaboration on the concepts was also very nice and informative!

thanks
Sanjay