Open jadchaar opened 3 years ago
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.
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.
Yup, all timezone's of type
str
are passed to theTzinfoParser
. 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.
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?
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
, ordateutil.tz.gettz
. This will allow for full feature encapsulation within Arrow, so users can create timezones like this:This
arrow.timezone
wrapper can simply wrap theTzinfoParser
anddateutil.tz.gettz
logic and expose an easy-to-use interface for users.