<story><title>Arrow: Better dates and times for Python</title><url>http://crsmithdev.com/arrow/</url></story><parent_chain></parent_chain><comment><author>jessedhillon</author><text>Seems like it&amp;#x27;s written by someone who prefers Ruby or JavaScript -- where there exists already a culture using names which are cute first, even if they are opaque -- over Python. These method naming choices are baffling&lt;p&gt;Arrow.to() converts to a new timezone? And .replace() applies a relative offset!? Replace the hour field of this object with -1 should not return an object having hour=11. Arrow.get() is doing some kind of quadruple duty, neither of which would I describe as &amp;quot;getting.&amp;quot;&lt;p&gt;And what about that class name? Arrow as the name of a package is fine, but what do you expect someone to make of &amp;lt;Arrow [...]&amp;gt; -- what&amp;#x27;s wrong with arrow.DateTime?&lt;p&gt;Great work on making and releasing something, but this API is surprising -- as in, one would be unable to predict how it works. I will continue using python-dateutil</text></comment>
<story><title>Arrow: Better dates and times for Python</title><url>http://crsmithdev.com/arrow/</url></story><parent_chain></parent_chain><comment><author>calpaterson</author><text>Suggestion: rename arrow.now() to arrow.localnow() to make it even clearer that it does not generate utc.  I&amp;#x27;ve run into this mistake many times with datetime.now() vs datetime.utcnow()</text></comment>