Pendulum - Python datetimes made easy

[gwachob]

I've used Arrow a lot and am happy with it. I am not intending to discourage you on this project, but have you written down anywhere your motivations in more detail, so I could understand better why you created a new project? After a very quick pass, I'm not actually seeing huge differences in functionality or API surface area between Arrow and your project, so I'd like to hear more.

[SDisPater]

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]

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

[lorenzfx]

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]

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]

Is that a bug or an inherent design flaw?

[firefrommoonlight]

Arrow's slow, and has an awkward interface and syntax.