Create arrow timezone interface and wrapper

[jadchaar]

Feature Request

It would be useful for users to directly import an arrow timezone object and create Arrow timezones rather than having to use datetime.timezone, ZoneInfo, or dateutil.tz.gettz. This will allow for full feature encapsulation within Arrow, so users can create timezones like this:

import arrow
arrow.now(tz=arrow.timezone("US/Pacific"))

This arrow.timezone wrapper can simply wrap the TzinfoParser and dateutil.tz.gettz logic and expose an easy-to-use interface for users.

[b10011]

There's even easier way to do this already:

import arrow
arrow.now(tz="US/Pacific")

I haven't seen a single function in arrow that didn't support strings as timezone definition. Additionally, arrow supports the "local" timezone.

[jadchaar]

Yup, all timezone's of type str are passed to the TzinfoParser. I totally agree, I think arrow's support for timezone string parsing might make this feature kind of pointless. @krisfremen @systemcatch what do you all think? I think @b10011 has a good point.

[b10011]

Yup, all timezone's of type str are passed to the TzinfoParser. I totally agree, I think arrow's support for timezone string parsing might make this feature kind of pointless. @krisfremen @systemcatch what do you all think? I think @b10011 has a good point.

Your point of view also has its advantages, for example, it's more optimal to only parse the timezone once, but I think if one is optimizing at such a detailed level, one wouldn't care that much about using dateutil.tz.gettz at that point. Also, dateutil.tz.gettz doesn't support local, instead you need to use dateutil.tz.tzlocal (you can't select local timezone using string). At the same time arrow.timezone would be a nice touch but on the other hand, it's use cases are quite limited.

[krisfremen]

I think the timezone approach would be very nice to have, even if the benefits are marginal.

Would be nice if it's extended to do some timezone arithmetic without an actual date time behind it?