Arrow: Better dates and times for Python

Seems like it&#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<p>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 &quot;getting.&quot;<p>And what about that class name? Arrow as the name of a package is fine, but what do you expect someone to make of &lt;Arrow [...]&gt; -- what&#x27;s wrong with arrow.DateTime?<p>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

I think Arrow still leaves too much confusion around how to handle timezones. That&#x27;s why I wrote DMC(<a href="https://github.com/rhettg/dmc" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rhettg&#x2F;dmc</a>).<p>Not to be confused with Delorean (<a href="https://github.com/myusuf3/delorean" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;myusuf3&#x2F;delorean</a>) which is a lot like Arrow.

Suggestion: rename arrow.now() to arrow.localnow() to make it even clearer that it does not generate utc. I&#x27;ve run into this mistake many times with datetime.now() vs datetime.utcnow()

Arrow is ambiguous when dealing with timezones, a lot of the high functionality ideas were copied from Delorean. Delorean has many more sensible default and is clear about educating people about naive vs. localized datetimes and a lot more sane.<p>Documentation is very educational too well worth the read. <a href="http://delorean.readthedocs.org/en/latest/" rel="nofollow">http:&#x2F;&#x2F;delorean.readthedocs.org&#x2F;en&#x2F;latest&#x2F;</a>

Is there any language that got the date &amp; time library right the first time? It seems like people always suggest to use a third party library. JavaScript has Moment.js, Java has Joda-Time, and now Python has Arrow.

Y&#x27;all may wanna check out python dateutil. <a href="https://labix.org/python-dateutil" rel="nofollow">https:&#x2F;&#x2F;labix.org&#x2F;python-dateutil</a>

Nice. One thought: why do you call it arrow? I know you can call it anything you want, but one reason requests is so popular because the name totally makes sense. My little 0.2 is why not rename it to pydate or something more intuitive.<p>What&#x27;s the difference between .utcnow() and .now()? Is one supposed to be an alias or is .now() default to the time the platform is set to?<p>I&#x27;ve opened an issue regarding calling convention. What do HNer think?<p><a href="https://github.com/crsmithdev/arrow/issues/125" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;crsmithdev&#x2F;arrow&#x2F;issues&#x2F;125</a>

The library looks really nice usability wise.<p>The arrow.get function tries a bit too hard to be user-friendly ; it lets me wondering if a value could have an unexpected interpretation.<p>One use-case that seem to be missing is time deltas. There is a support for time iteration but I don&#x27;t see a good way to transform two timestamps into a time interval.

This is a very interesting problem to tackle for all runtimes.<p>In my experience, the main issues are: [1] How do we store the date &#x2F; time fields in the database tier [2] How do we display those fields to users in multiple time zones and cultures and gather validated input from those cultures [3] How do we do date &#x2F; time math in a simple manner<p>Issue [1] has implications for manipulating data directly (i.e. querying or reporting). Should the data be stored in UST or in some &quot;local timeframe&quot;?<p>Issue [2] always seems to trip some developers: how do we render a time or date in a way that makes sense in a global world (i.e. &quot;8&#x2F;5&#x2F;2014&quot; vs. &quot;5&#x2F;8&#x2F;2014&quot; vs. &quot;5-8-2014&quot; or 3:26 PM vs 3:26 etc).<p>Issue [3] is always a pain too, based on whatever decisions were made for [1] and [2].<p>Test of awesomeness: if your code works in Hebrew or Thai cultures!

It would be cool if python could support date&#x2F;timestamp literals.<p>I&#x27;ve implemented something similar in a query language I wrote, where dates are represented similar to ISO 8601 format:<p><pre><code> d&#x27;2014-12-01&#x27; t&#x27;2014-12-01 12:52&#x27; t&#x27;2014-12-01 12:52 PST&#x27; t&#x27;2014-12-01T12:52:20.0820Z&#x27; t&#x27;2014-12-01T12:52:20.0820+08.00&#x27;</code></pre>

Looks promising! Although author said that moment.js was an inspiration, I&#x27;m glad that he didn&#x27;t implement .replace functionality as mutation like moment does. It was a constant source of errors.

Ah, this is lovely. If there&#x27;s one routine thing I trip up over again and again, it&#x27;s times, every time. Big fan, nice work. Will definitely look at using this next project.

Looks nice. I noticed the ceil function has an offset of one microsecond, this way it is not consistent with e.g. ceil in numpy. What was the reason for this?

Very nice! This replaces a lot of code I&#x27;m manually implementing now, to do things like humanize() and floor()&#x2F;ceil()

I&#x27;ve used this in the past. Good, well-written library. The stdlib datetime&#x2F;time modules are such a PITA sometimes.

There are too many ways to do something, best implement the One True Way.<p>There&#x27;s an obligatory xkcd somewhere on this...

This might be what I am looking for since I looked at the datetime docs the first time years ago.

re. parsing and formatting tokens: because what we needed was yet another date&#x2F;time pattern format which looks like LDML&#x27;s but behaves completely differently.

Very nice, thank you, definitely using this in new code.

It would be better to stop reinventing this wheel.