7 ms·

How does it differ from Arrow which was made several years ago? [1] [1] http://crsmithdev.com/arrow/ http://crsmithdev.com/arrow/

by bndr 10y ago

smegel 10y ago
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?
- kenneth_reitz 10y ago
  that's why there's `maya.when('yesterday', timezone='US/Eastern')` :)
  - Drdrdrq 10y ago
    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!
    - StavrosK 10y ago
      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.
      - prashnts 10y ago
        Shouldn't it be immutable? I'd expect this to be a default behaviour.
        amjd 10y ago
        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).
        paulddraper 10y ago
        In this case, consistency would imply the immutability of time.
      - webmaven 10y ago
        Shouldn't it round up?
        StavrosK 10y ago
        If it's 01:00:01, is it two hours?
        Redoubts 10y ago
        If it's 00:59:50, is it 0 hours? i have the feeling his natural answer to both questions is no...
        webmaven 10y ago
        Fine, rounding up fails. Round to nearest time unit, instead.
    - misnome 10y ago
      Why on earth is 'tomorrow' just +24 (local) hours. I'd expect it to be the next calendar date.
      - jibsen 10y ago
        I suppose due to DST, the same clock time on the next calendar date might not exist or be ambiguous.
        pherq 10y ago
        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.
      - icebraining 10y ago
        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.
- Singletoned 10y ago
  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.
  - daenney 10y ago
    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.
crdoconnor 10y ago
Or Pendulum. Which is kind of a better arrow: https://github.com/sdispater/pendulum https://github.com/sdispater/pendulum
- djrobstep 10y ago
  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.
  - daenney 10y ago
    > 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.
jessedhillon 10y ago
The unpythonic interface for Arrow stands out sorely in Python codebases.
- DasIch 10y ago
  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.

How does it differ from Arrow which was made several years ago? [1] [1] http://crsmithdev.com/arrow/ http://crsmithdev.com/arrow/

by bndr 10y ago

How does it differ from Arrow which was made several years ago? [1] [1] http://crsmithdev.com/arrow/ http://crsmithdev.com/arrow/

smegel 10y ago

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?

kenneth_reitz 10y ago
that's why there's `maya.when('yesterday', timezone='US/Eastern')` :)
- Drdrdrq 10y ago
  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!
  - StavrosK 10y ago
    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.
    - prashnts 10y ago
      Shouldn't it be immutable? I'd expect this to be a default behaviour.
      - amjd 10y ago
        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).
      - paulddraper 10y ago
        In this case, consistency would imply the immutability of time.
    - webmaven 10y ago
      Shouldn't it round up?
      - StavrosK 10y ago
        If it's 01:00:01, is it two hours?
        Redoubts 10y ago
        If it's 00:59:50, is it 0 hours? i have the feeling his natural answer to both questions is no...
        webmaven 10y ago
        Fine, rounding up fails. Round to nearest time unit, instead.
  - misnome 10y ago
    Why on earth is 'tomorrow' just +24 (local) hours. I'd expect it to be the next calendar date.
    - jibsen 10y ago
      I suppose due to DST, the same clock time on the next calendar date might not exist or be ambiguous.
      - pherq 10y ago
        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.
    - icebraining 10y ago
      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.
Singletoned 10y ago
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.
- daenney 10y ago
  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.

crdoconnor 10y ago

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

djrobstep 10y ago
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.
- daenney 10y ago
  > 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.

jessedhillon 10y ago

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

DasIch 10y ago
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.