Hacker News Reader

Comment by smegel | Hacker News Reader

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?

View on HN

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!

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.

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

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.

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

Reply on news.ycombinator.com