4 ms·

Python datetimes used with timezones, even UTC, are ridiculously slow and bloated. It's puzzling why this doesn't wrap np.datetime64 instead. Or wrap boost.date

Python datetimes used with timezones, even UTC, are ridiculously slow and bloated. It's puzzling why this doesn't wrap np.datetime64 instead. Or wrap boost.datetime. There are many good options to claw some performance back so it's really head-scratch inducing that someone would recognize that stdlib datetime is a dog and then wrap it instead of scrapping it.

aangjie 10y ago
> It's puzzling why this doesn't wrap np.datetime64 instead. Perhaps to avoid the numpy dependency. I've found numpy a bit heavy and wouldn't want to depend on it simply for the sake of some datetime syntax. May be boost.datetime or even numpy's implementantion on datetime, but that sounds like a lot of maintenance.
- guitarbill 10y ago
  Agree, 100%. E.g. numpy in a virtual environment can be a real pain. Best case, it takes a bit longer to install. Worst case, it's on a system that's missing some OS specific dependencies. "Works for me" is not okay for stuff on PyPI.
  - aangjie 10y ago
    Hmm.. that's making me rethink that 'datascienceutils' project I put up on pypi.. May be work on getting it to stable version before pushing to pypi..
deleted 10y ago
[deleted]
daenney 10y ago
> It's puzzling why this doesn't wrap np.datetime64 instead. Or wrap boost.datetime. I don't find it that puzzling. It's meant to help deal with timezones, efficiency isn't necessarily part of that equation. And if I were to write a simple CLI or web app I would avoid anything that would pull in a dependency like numpy or require a C-library plus its bindings. If you need to manipulate a huge amount of date times and this is something your app is constantly doing then sure, optimise for that.
robochat 10y ago
There is a library called udatetime that claims to be very fast at parsing RFC3339 https://github.com/freach/udatetime https://github.com/freach/udatetime
TylerE 10y ago
Or perhaps even better use conditional imports and do progressive fallback.

aangjie 10y ago

> It's puzzling why this doesn't wrap np.datetime64 instead. Perhaps to avoid the numpy dependency. I've found numpy a bit heavy and wouldn't want to depend on it simply for the sake of some datetime syntax. May be boost.datetime or even numpy's implementantion on datetime, but that sounds like a lot of maintenance.

guitarbill 10y ago
Agree, 100%. E.g. numpy in a virtual environment can be a real pain. Best case, it takes a bit longer to install. Worst case, it's on a system that's missing some OS specific dependencies. "Works for me" is not okay for stuff on PyPI.
- aangjie 10y ago
  Hmm.. that's making me rethink that 'datascienceutils' project I put up on pypi.. May be work on getting it to stable version before pushing to pypi..

deleted 10y ago

[deleted]

daenney 10y ago

> It's puzzling why this doesn't wrap np.datetime64 instead. Or wrap boost.datetime. I don't find it that puzzling. It's meant to help deal with timezones, efficiency isn't necessarily part of that equation. And if I were to write a simple CLI or web app I would avoid anything that would pull in a dependency like numpy or require a C-library plus its bindings. If you need to manipulate a huge amount of date times and this is something your app is constantly doing then sure, optimise for that.

robochat 10y ago

There is a library called udatetime that claims to be very fast at parsing RFC3339 https://github.com/freach/udatetime https://github.com/freach/udatetime

TylerE 10y ago

Or perhaps even better use conditional imports and do progressive fallback.