Suggestion: rename arrow.now() to arrow.localnow() to make it even clearer that it does not generate utc. I've run into this mistake many times with datetime.now() vs datetime.utcnow()
This library is a couple years old already (version 0.1.6 hit PyPi in Nov 2012). A rename at this point seems unlikely.
Unlike datetime.now() and datetime.utcnow(), arrow.now() produces a datetime that includes tzinfo. As long as that's on there and correct, I think the risk you describe is low.
Python’s standard library and some other low-level modules have near-complete date, time and time zone functionality but don’t work very well from a usability perspective:
Why be consistent with something that suffers from usability problems?
It's a shame that Python's time/date stuff is so wonky. I see stuff like dateutils and arrow and just wish I didn't have to go elsewhere for such core functionality.
Not that it's a big deal to loop in external dependencies or anything, I just see newer (and experienced) Python devs trip up on stuff like TZ aware/naive times. Also, dateutil's relativedelta is so nice compared to the built-in timedelta!
It's a shame that Python's time/date stuff is so wonky. I see stuff like dateutils and arrow and just wish I didn't have to go elsewhere for such core functionality.
That's on point, and you're not alone. It's a little frustrating when you have to take a detour to get something done. There's that extra hurdle. That said, user friendliness, developer friendliness, and maintainability are all about using the best tools for the job. If arrow is that tool, then so be it.
user friendliness, developer friendliness, and maintainability are all about using the best tools for the job
Definitely. The most unfortunate part of this is that people who are newer to the ecosystem won't really know where to go or what they're even looking for, necessarily.
Comments
Suggestion: rename arrow.now() to arrow.localnow() to make it even clearer that it does not generate utc. I've run into this mistake many times with datetime.now() vs datetime.utcnow()
This library is a couple years old already (version 0.1.6 hit PyPi in Nov 2012). A rename at this point seems unlikely.
Unlike datetime.now() and datetime.utcnow(), arrow.now() produces a datetime that includes tzinfo. As long as that's on there and correct, I think the risk you describe is low.
I'm the other way around, consistency with the standard library (even if that decision was a mistake) will increase learn-ability.
From the webpage:
Why be consistent with something that suffers from usability problems?
It's a shame that Python's time/date stuff is so wonky. I see stuff like dateutils and arrow and just wish I didn't have to go elsewhere for such core functionality.
Not that it's a big deal to loop in external dependencies or anything, I just see newer (and experienced) Python devs trip up on stuff like TZ aware/naive times. Also, dateutil's relativedelta is so nice compared to the built-in timedelta!
That's on point, and you're not alone. It's a little frustrating when you have to take a detour to get something done. There's that extra hurdle. That said, user friendliness, developer friendliness, and maintainability are all about using the best tools for the job. If arrow is that tool, then so be it.
Definitely. The most unfortunate part of this is that people who are newer to the ecosystem won't really know where to go or what they're even looking for, necessarily.
author here: the other commenters here are correct, I used .now() and .utcnow() in order to match the stdlib API.