Return full Olsen timezone from an arrow object

[shankari]

I've been using arrow for a while in my project, and I really like the clean semantics around timezones. However, I just ran into a small hole in timezone support, and I'm really hoping you can fix it, or at least, tell me how to work around it.

Here's my use case:

• I want to retrieve the timezone from an arrow object
• I want to save that timezone (as part of a JSON object)
• I want to retrieve that timezone and use it to reconstruct a new arrow object

Seems straightforward, right?

Not so fast!

arrow does not have timezone or tz attributes

In [8]: arrow.Arrow(year=2016, month=3, day=1, tzinfo=tz.gettz("Asia/Calcutta")).timezone---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-8-31b6cb046991> in <module>()
----> 1 arrow.Arrow(year=2016, month=3, day=1, tzinfo=tz.gettz("Asia/Calcutta")).timezone

/Users/shankari/OSS/anaconda/lib/python2.7/site-packages/arrow/arrow.pyc in __getattr__(self, name)
    313                 return value
    314 
--> 315         return object.__getattribute__(self, name)
    316 
    317     @property

AttributeError: 'Arrow' object has no attribute 'timezone'

In [9]: arrow.Arrow(year=2016, month=3, day=1, tzinfo=tz.gettz("Asia/Calcutta")).tz
---------------------------------------------------------------------------
AttributeError                            Traceback (most recent call last)
<ipython-input-9-28efc76a5b3d> in <module>()
----> 1 arrow.Arrow(year=2016, month=3, day=1, tzinfo=tz.gettz("Asia/Calcutta")).tz

/Users/shankari/OSS/anaconda/lib/python2.7/site-packages/arrow/arrow.pyc in __getattr__(self, name)
    313                 return value
    314 
--> 315         return object.__getattribute__(self, name)
    316 
    317     @property

AttributeError: 'Arrow' object has no attribute 'tz'

It does have a tzinfo defined, but that returns a tzfile

In [10]: arrow.Arrow(year=2016, month=3, day=1, tzinfo=tz.gettz("Asia/Calcutta")).tzinfo
Out[10]: tzfile('/usr/share/zoneinfo/Asia/Calcutta')

And there does not appear to be an easy way to extract the Asia/Calcutta from the tzfile - using obvious methods like tzname just return 'IST'

In [11]: arrow.Arrow(year=2016, month=3, day=1, tzinfo=tz.gettz("Asia/Calcutta")).tzname()
Out[11]: 'IST'

In [12]: a = arrow.Arrow(year=2016, month=3, day=1, tzinfo=tz.gettz("Asia/Calcutta"))

In [13]: a.tzinfo.tzname(a.datetime)
Out[13]: 'IST'

And since 'IST' is not a valid OLSON timezone, it cannot be used to look up the timezone while creating a new Arrow object.

In [14]: arrow.Arrow(year=2016, month=3, day=1, tzinfo=tz.gettz("Asia/Calcutta"))
Out[14]: <Arrow [2016-03-01T00:00:00+05:30]>

In [15]: arrow.Arrow(year=2016, month=3, day=1, tzinfo=tz.gettz("IST"))
Out[15]: <Arrow [2016-03-01T00:00:00+00:00]>

Any thoughts/suggestions?

[nugend]

This is an upstream issue with dateutil. The tz.gettz method doesn't preserve the timezone name. You might be able to get them to fix it.

Alternatively, you could explicitly use pytz which stores the zone name in the tz objects it creates

>>> arrow.now(pytz.timezone('Asia/Calcutta')).tzinfo.zone
'Asia/Calcutta'

[andrewelkins]

@nugend Has got it right there. We'll add this to the forth coming wiki/tips page

[akshayah3]

>>> arrow.now(pytz.timezone('Asia/Calcutta')).tzinfo.zone 'Asia/Calcutta'

@nugend @andrewelkins I am trying to reproduce this but unable to get the above output. The tzinfo call returns a tzfile which doesn't have a zone attribute

[systemcatch]

Hi @akshayah3 arrow now uses dateutil tzinfos everywhere which is why the example code no longer works.

[jadchaar]

Reopening this issue so that we get this addressed.

[akshayah3]

So is there a way in arrow to get the full time zone string like Asia/Kolkata?

Right now I am doing a hack where I parse the tzfile string to get this

[systemcatch]

There is an issue about implementing support for this (https://github.com/dateutil/dateutil/issues/76) in the dateutil repo. I might take a look at doing it since it's a useful feature.

Until then you'll have to rely on parsing the tzfile name.

[systemcatch]

If we choose to implement PEP 615 the ZoneInfo objects from that would allow us to do this easily.