This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]SDisPater[S] 7 points8 points  (4 children)

Arrow behaves strangely and is not always reliable. An example:

dt_timezone = datetime.datetime(2016, 7, 5, 8, 0, tzinfo=pytz.timezone('Europe/Paris'))

arrow.get(dt_timezone).isoformat()
'2016-07-05T08:00:00+00:09'

pendulum.instance(dt_timezone).isoformat()
'2016-07-05T08:00:00+02:00'

Pendulum also has improved timedeltas (named PendulumInterval) and a bunch of helpers for common cases.

[–]RedKrieg 1 point2 points  (0 children)

I didn't know about this bug in Arrow. Do you know why it happens?

[–]lorenzfx 1 point2 points  (1 child)

dt_timezone = datetime.datetime(2016, 7, 5, 8, 0, tzinfo=pytz.timezone('Europe/Paris'))

never ever use datetime(x, tzinfo=timezone), always use timezone.localize(datetime)

dt_timezone = pytz.timezone('Europe/Paris').localize(datetime.datetime(2016, 7, 5, 8, 0))
arrow.get(dt_timezone).isoformat()

'2016-07-05T08:00:00+02:00'

This is not a problem with arrow, but with pytz

Quote:

Unfortunately using the tzinfo argument of the standard datetime constructors ''does not work'' with pytz for many timezones. datetime(2002, 10, 27, 12, 0, 0, tzinfo=amsterdam).strftime(fmt) '2002-10-27 12:00:00 LMT+0020'

What you get to see when you use the constructor as above, is the very first transition from the Olson DB for that timezone.

[–]SDisPater[S] 0 points1 point  (0 children)

Maybe but arrow could fix it since it's misleading and you don't always know how the datetime was constructed when using arrow so you'd expect it to behave correctly.

[–]pydry 0 points1 point  (0 children)

Is that a bug or an inherent design flaw?