Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pendulum – Python datetimes made easy

github.com

Post reply on HN
Print view View original

21–30 of 76 posts

Re: Pendulum – Python datetimes made easy

#21

Post by tedmiston »

bjt wrote: post #5
forgotpwtomain wrote: post #3

Python stdlib datetime/time/calendar libs are junk. That one constantly has to read obscure function signatures in the docs to do rather obvious things is just awful. On the otherhand if you've e.g. Ruby/Rails datetime handling than you get used to reasonable things working ( such as Time.now + 1.day ) that Arrow doesn't handle well. As a matter of fact Arrow got rid of DT deltas and seemingly made the situation wors…

1.day? I confess to not being a Rubyist, but does that require monkeypatching the base int class? I don't see anything unreasonable about Pendulum's interface. Let's let Python be Python and Ruby be Ruby.

Similar idea to Ruby's .times() method [0].

[0]: http://ruby-doc.org/core-1.9.3/Integer.html#method-i-times

Re: Pendulum – Python datetimes made easy

#22

Post by tedmiston »

sdispater wrote: post #2

Pendulum is a new library for Python to ease datetimes, timedeltas and timezones manipulation. It is heavily inspired by [Carbon]( http://carbon.nesbot.com ) for PHP. Basically, the Pendulum class is a replacement for the native datetime one with some useful and intuitive methods, the Interval class is intended to be a better time delta class and, finally, the Period class is a datetime-aware timedelta. Timezones are…

I can't decide if auto-normalizing my times to DST is a feature or anti-feature. If I didn't know it was there, I would consider it a surprising default.

Re: Pendulum – Python datetimes made easy

#23

Post by tedmiston »

I've been happily using django.utils.timezone for a while now and doing everything on the backend in UTC. For any user-facing timestamps, to some degree I'd rather keep that in the front end and a separate concern from my API.

Not saying storing user timezone and converting on the backend is bad; but this is simpler when localized timestamps aren't a core part of my app.

Re: Pendulum – Python datetimes made easy

#24

Post by sdispater »

tedmiston wrote: post #22
sdispater wrote: post #2

Pendulum is a new library for Python to ease datetimes, timedeltas and timezones manipulation. It is heavily inspired by [Carbon]( http://carbon.nesbot.com ) for PHP. Basically, the Pendulum class is a replacement for the native datetime one with some useful and intuitive methods, the Interval class is intended to be a better time delta class and, finally, the Period class is a datetime-aware timedelta. Timezones are…

I can't decide if auto-normalizing my times to DST is a feature or anti-feature. If I didn't know it was there, I would consider it a surprising default.

I see what you mean but as soon as you deal with timezone-aware datetimes you don't really have a choice, if an hour has been skipped, it simply doesn't exist.

What is important here, I think, is that any time arithmetic is not affected by this normalization, so if you add an hour the difference will be an hour, so you don't really have to think about it.

Re: Pendulum – Python datetimes made easy

#25

Post by jsmeaton »

sdispater wrote: post #2

Pendulum is a new library for Python to ease datetimes, timedeltas and timezones manipulation. It is heavily inspired by [Carbon]( http://carbon.nesbot.com ) for PHP. Basically, the Pendulum class is a replacement for the native datetime one with some useful and intuitive methods, the Interval class is intended to be a better time delta class and, finally, the Period class is a datetime-aware timedelta. Timezones are…

Cool library, I'll definitely be looking into this more closely in the future. The automatic handling of ambiguous time during timezone transitions is curious. As an example, Django punts on automatic handling and requires a user to choose between pre and post transition (I wrote the is_dst handling): https://github.com/django/django/blob/19e20a2a3f763388bba926...

What if you were to begin with a time at 3:30 and then subtract an hour. Would your library properly return 1:30? What if a user had a naive time at 3:30, subtracted an hour, and then converted to an aware time using your library? For what it's worth, I think moving to 3:30 is the correct behaviour in the vast amount of cases. Requiring a user to provide a direction to move and throwing an exception if they don't is dangerous. How often are users going to see this exception, if at all? Just wondering how much you've considered cases, if they exist, that would be better off moving to 1:30.

I'll add one more thing. As soon as I started browsing the page I thought "why would I use this over arrow?". Great to see you addressed that by default. I didn't know about some of arrows shortcomings/bugs, so they were really useful.

Handling dates, times, and timezones in particular is a tricky problem, as evident by the large number of libraries in each language trying to get it right. If you haven't already, I'd really recommend reading the blog posts of Jon Skeet regarding Noda Time http://blog.nodatime.org/ and https://codeblog.jonskeet.uk/category/nodatime/ even if it turns up some corner cases you haven't considered, or validates ones you have.

Thanks!

Re: Pendulum – Python datetimes made easy

#26

Post by jsmeaton »

tedmiston wrote: post #23

I've been happily using django.utils.timezone for a while now and doing everything on the backend in UTC. For any user-facing timestamps, to some degree I'd rather keep that in the front end and a separate concern from my API. Not saying storing user timezone and converting on the backend is bad; but this is simpler when localized timestamps aren't a core part of my app.

Yes, always work in UTC. But you could use this library to convert user provided naive datetimes to UTC, and datetimes coming from the database into localised datetimes. Converting from/to timezones other than UTC in Django isn't as nice as it could be.

Re: Pendulum – Python datetimes made easy

#27

Post by oneweekwonder »

detaro wrote: post #15
antar wrote: post #12

Earlier quoted context omitted.

Why not submit fixes for the existing library instead?

Can't talk about the specific complaints the author has, but there are a bunch of datetime libraries for python with often intentionally different behaviors. Submitting "fixes" requires the other libraries' authors to see what you want to fix as a defect and not a design decision/feature/to irrelevant to justify breaking changes. At least that was my impression from trying to find a combination of libraries I like an…

What mysql lib would you recommend?

I'm doing a `pip install https://dev.mysql.com/get/Downloads/Connector-Python/mysql-c... on older centos boxes. Because I found `pip install mysql-connector-python` seems to fail on older boxes.

I also wonder if I should not start to look at SQLAlchemy. Not so much the ORM. But rather the simple DBAPI[0] interface.

I'm already using Postgres FDW to integrate PostGIS into our mysql dbs. So I am going to drag a Postgres python lib around in the near future, any recommendations.

PS: I Believe I just convinced myself, to go invest some time into learning SQLAlchemy.

http://aosabook.org/en/sqlalchemy.html

Re: Pendulum – Python datetimes made easy

#28

Post by Walkman »

sdispater wrote: post #24
tedmiston wrote: post #22

Earlier quoted context omitted.

I can't decide if auto-normalizing my times to DST is a feature or anti-feature. If I didn't know it was there, I would consider it a surprising default.

I see what you mean but as soon as you deal with timezone-aware datetimes you don't really have a choice, if an hour has been skipped, it simply doesn't exist. What is important here, I think, is that any time arithmetic is not affected by this normalization, so if you add an hour the difference will be an hour, so you don't really have to think about it.

> I see what you mean but as soon as you deal with timezone-aware datetimes you don't really have a choice, if an hour has been skipped, it simply doesn't exist.

So somebody clearly made a mistake (either the user or the programmer not checking the input) which you can't automagically fix. Well, at least, it's a terrible idea.

I understand the intent of helping them, but you make more harm this way.

It's also against the ZEN of Python.

Re: Pendulum – Python datetimes made easy

#29

Post by Walkman »

I don't understand why this library exists. I am (literally) manipulating datetimes for a living in a Django app this whole year and we don't even have Arrow installed. Pytz and maybe dateutil is all you need.

Also I really hate when someone fragment the energy and their time making a new, inferior library instead of fixing and patching the existings for basic things like this. This way we will have a bunch of incomplete, inferior libraries which all have quirks instead of only one really good one which could everybody use...

Re: Pendulum – Python datetimes made easy

#30

Post by Animats »

This area is prone to severe bikeshedding. Back in 2012, I filed a Python bug, "datetime: add ability to parse RFC 3339 dates and times"[1] RFC 3339 timestamps appear in email, RSS feeds, etc. The datetime library could output them, but not parse them. There are at least seven parsing functions in PyPi for them, and each has some major problem.

There have been steady discussions of this issue for almost four years now. I dropped out years ago, but the arguments go on.

[1] https://bugs.python.org/issue15873

Post reply on HN