4 ms·

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.n

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()

timClicks 12y ago
I'm the other way around, consistency with the standard library (even if that decision was a mistake) will increase learn-ability.
- coherentpony 12y ago
  From the webpage: > 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?
  - gtaylor 12y ago
    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!
    - coherentpony 12y ago
      > 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.
      - gtaylor 12y ago
        > 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.
bjt 12y ago
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.
crsmithdev 12y ago
author here: the other commenters here are correct, I used .now() and .utcnow() in order to match the stdlib API.
mVChr 12y ago
"""calpaterson's awesome project""" import arrow arrow.localnow = arrow.now del arrow.now

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()

timClicks 12y ago

I'm the other way around, consistency with the standard library (even if that decision was a mistake) will increase learn-ability.

coherentpony 12y ago
From the webpage: > 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?
- gtaylor 12y ago
  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!
  - coherentpony 12y ago
    > 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.
    - gtaylor 12y ago
      > 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.

bjt 12y ago

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.

crsmithdev 12y ago

author here: the other commenters here are correct, I used .now() and .utcnow() in order to match the stdlib API.

mVChr 12y ago

"""calpaterson's awesome project""" import arrow arrow.localnow = arrow.now del arrow.now