Or Pendulum. Which is kind of a better arrow: https://github.com/sdispater/pendulum

Pendulum is the best of these libraries imho. A couple of rough edges API wise but mostly great and the best feature is the fact that pendulum objects are actual stdlib datetime instances too and so can be used interchangably with code that expects stdlib datetimes.

> the best feature is the fact that pendulum objects are actual stdlib datetime instances too

Exactly this. Makes it so much easier especially when you need to work with other components that only understand the stdlib datetime.

That would be nice to know. Arrow still seems active, and has been consistently so over the last 3 years.

I have a bit of doubt about a time library that defaults to UTC but uses human phrases like "tomorrow". Who thinks about UTC tomorrow?

that's why there's `maya.when('yesterday', timezone='US/Eastern')` :)

That's great, but why this then:

    >>> tomorrow = maya.when('tomorrow') 
    <MayaDT epoch=1481919067.23> 
    >>> tomorrow.slang_date() 
    'tomorrow' 
    >>> tomorrow.slang_time() 
    '23 hours from now'

Huh? Given that we never specified timezone, I would expect 24h (unless DST change happens).

This is actually my biggest gripe with date+time libs. Imho API should always be explicit in what its default TZ is.

EDIT: still, appreciate what you are doing. Requests rule, and there are many other areas (including datetime) that need libs with better APIs. Thumbs up!

Why on earth is 'tomorrow' just +24 (local) hours. I'd expect it to be the next calendar date.

Next calendar date according to which calendar? Not all places in the world are on the same date, so if you don't indicate the timezone, there's no way to tell what the next calendar date is.

I suppose due to DST, the same clock time on the next calendar date might not exist or be ambiguous.

Conversely, +24 hours may fall on the same calendar date or two calendar days on from now.

Really, "tomorrow" should be the interval from the beginning of the next calendar date to the end.

I'm pretty sure that it's 23 because some time passed between keystrokes, so the delta was 23:59:50, and he only keeps the most significant digit. I had to do this exact thing yesterday for timetaco.com.

Shouldn't it be immutable? I'd expect this to be a default behaviour.

Not in this case. The entire proposition of slang_time is that it returns human readable time difference with respect to now (i.e., the moment when called).

In this case, consistency would imply the immutability of time.

Shouldn't it round up?

If it's 01:00:01, is it two hours?

If it's 00:59:50, is it 0 hours?

i have the feeling his natural answer to both questions is no...

Fine, rounding up fails.

Round to nearest time unit, instead.

I have a lot of doubt about a time library that defaults to UTC at all.

Having spent a lot of time dealing with timezones, I have a strong feeling that naive should be the default unless explicitly given a timezone, and your code should blow up when it is given them (or possibly gracefully fail).

Admittedly I haven't had a chance to play with maya as I haven't been able to get it to install.

Naïve is what usually gets everyone into trouble since you have no frame of reference and you need to do all kinds of magic to try and deduce timezones and adapt to it. It also makes it utterly impossible to properly deal with DST changes etc. unless you know that everyone using your system is coming from the same TZ.

I don't like the default of UTC either though. Explicit is better than implicit, so make people always specify a timezone instead which avoids all form of ambiguity.

The unpythonic interface for Arrow stands out sorely in Python codebases.

I'm not sure I would call Maya particularly pythonic and just like all the other libraries it's API seems to be focused more on fixing issues in other libraries than actually thinking through the problem.