Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Maya – Python Datetimes for Humans

kennethreitz.org

Post reply on HN
Print view View original

91–100 of 180 posts

Re: Maya – Python Datetimes for Humans

#91

Post by vegabook »

Goopplesoft wrote: post #85

Kenneth Reitz is a testament to how important good interfaces are in the developer community. There are literally 0 interesting things in the code (all dependency driven, https://git.io/v15i3 ). It does have a nice interface and because of this it will probably become one of the more popular python datetime libs.

Arguably bringing multiple dependencies under one roof, with a nice, human-readable interface, is exactly what the value is here. This SO answer from Pandas lead Wes Mckinney says it better than anything I could comment. Python datetime/timestamp management: "Welcome to Hell"

http://stackoverflow.com/questions/13703720/converting-betwe...

I run batch and real time financial feeds into Python from multiple sources, inevitably from different programming language paradigms, and with different time/date/timezone conventions, and then I allow user interaction with it in their own lingo for dates and times, and my experience is that it is indeed hell consolidating all this into a common tongue. The "slang time" idea suggest to me that this library understands the need for flexibility and malleability in this very disjointed and often frustrating part of the Python ecosystem.

Re: Maya – Python Datetimes for Humans

#92

Post by detaro »

sametmax wrote: post #17

I wish Kenneth would have contributed to an existed project for once. Arrow and pendulum (my current favorite) have a very decent API. The later one is especially well tested for the numerous corner cases of date handling, which I doubt Kenneth got right on first try. For request, a full rewrite made sense because urllib sucked so much and we had no good alternatives. But for date time, alternative exists and they ar…

I'm not sure in this case. As it is now, Maya seems to be mostly a thin wrapper around existing libraries: it is all about the API, which is something where the authors of the various libraries seem to have very strong opinions about (with good reasons). There is not much in the way of actually re-implementing existing functionality, which I would see as a bigger issue.

Re: Maya – Python Datetimes for Humans

#93

Post by pherq »

jibsen wrote: post #78
misnome wrote: post #53

Earlier quoted context omitted.

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.

Re: Maya – Python Datetimes for Humans

#94

Post by jchassoul »

I don't understand the author's effort on solving this "problem"... I wonder if he considered at some point make a contribution to stable open-source existing libraries like arrow that even claim inspiration on one of his projects for the API. What's not for humans on the arrow API? what are the arguments for basically start yet another time library from scratch?, why is making a contribution not an option? probably the author of arrow will love your contributions and will love to hear the arguments on the changes you propose.

Re: Maya – Python Datetimes for Humans

#95

Post by niftich »

The link to its github was posted on HN when it was brand new, and I left a comment [6], which I'm reproducing here -- since most of my points still apply.

(...) take my very early comments with a grain of salt -- they refer to the progress as of this commit [1].

I love Requests -- its API design is fantastic, and manages to distill down most of a complex problem domain to a clean, dare-I-say, elegant API. So I can eagerly anticipate this design applied to datetimes. But the progress being shown so far is definitely not it.

>>> tomorrow = maya.when('tomorrow')

Why is "tomorrow" a precise-to-centisecond, infinitesimally small point on a giant cosmic timeline? I'm reasonably sure it's an abstract concept that describes the calendar day that starts after the current calendar day ends.

At least, Pendulum normalizes tomorrow() and its ilk to represent midnight on the given day [2], while Delorean's natural language methods [3] like next_day() advance the day while leaving the time-of-day unchanged, but the method name makes this fairly clear.

Even Arrow, which is heavily inspired by Moment.js to the point of conflating every single datetime idea into the same class, opts for mutators that are still more clear [4].

> Timezones fit in here somewhere...

Yeah, this needs more work.

Java 8 / Threeten, and its predecessor Joda-Time took the approach of clearly modeling each and every concept that humans actually use to describe time; even if you take issue with their API, the designers have clearly done their homework, and their data model is solid.

Formats like TOML wrestled with datetimes and realized [5] that datetimes aren't just woefully underspecified in most other specs and APIs, but that they're frequently mis-modeled, so they adopted large portions of Threeten's data model. Cases like this should merit strong consideration from anyone trying to propose new datetime APIs today.

[1] https://github.com/kennethreitz/maya/commit/ecd0166ba215c1a5.... [2] https://pendulum.eustace.io/docs/#instantiation [3] http://delorean.readthedocs.io/en/latest/quickstart.html#nat.... [4] http://crsmithdev.com/arrow/#replace-shift [5] https://news.ycombinator.com/item?id=12364805 [6] https://news.ycombinator.com/item?id=13190314#13190657

Re: Maya – Python Datetimes for Humans

#96

Post by dom0 »

vegabook wrote: post #91
Goopplesoft wrote: post #85

Kenneth Reitz is a testament to how important good interfaces are in the developer community. There are literally 0 interesting things in the code (all dependency driven, https://git.io/v15i3 ). It does have a nice interface and because of this it will probably become one of the more popular python datetime libs.

Arguably bringing multiple dependencies under one roof, with a nice, human-readable interface, is exactly what the value is here. This SO answer from Pandas lead Wes Mckinney says it better than anything I could comment. Python datetime/timestamp management: "Welcome to Hell" http://stackoverflow.com/questions/13703720/converting-betwe... I run batch and real time financial feeds into Python from multiple sources, in…

I think there are two separate issues here.

One thing is that some libraries bring their own not-really-different-just-different-enough-to-break-things date/time types to the table. That can be worked out over time, not that big of a problem, just inconvenient.

The other is that I've grown to think that the abstraction commonly used, seeing date/time as something like (year, month, day, hour, minute, second, subsecond, timezone) is in itself not really suitable, because the derived interfaces (like accessing and modifying days, months etc. separately) mean that most code working with these will inevitably be bug-ridden.

The root cause for this is imho that date and time are extremely complicated and it's usually unclear what the correct behaviour would be in any of the many, many edge cases.

Some examples:

1.) One week after `this` date. Does this mean, add seven days? What about leap days? Should the result be the same weekday, just in the next week instead?

2.) Start and end time of a process should be recorded. The process starts and finished. All good. The duration of the process is -1 hour and 5 minutes. Should instead a start timestamp be recorded and a monotonic duration? Or perhaps we should rather note the begin of a monotonic period and record an end timestamp, deriving the start timestamp? Which is correct?

3.) One ^W two words: recurrence rules

4.) DST

5.) Combining 3.) and 4.)!

dom's rule of thumb: if code does addition or substraction with some measure of time, it's probably wrong.

Re: Maya – Python Datetimes for Humans

#98

Post by scrollaway »

jchassoul wrote: post #94

I don't understand the author's effort on solving this "problem"... I wonder if he considered at some point make a contribution to stable open-source existing libraries like arrow that even claim inspiration on one of his projects for the API. What's not for humans on the arrow API? what are the arguments for basically start yet another time library from scratch?, why is making a contribution not an option? probably…

As rich as it is to tell Kenneth to "consider contributing to existing open source libraries", I have to agree: what's so exceptional about this library when Arrow is already a thing?

http://crsmithdev.com/arrow/

Re: Maya – Python Datetimes for Humans

#99

Post by detaro »

jchassoul wrote: post #94

I don't understand the author's effort on solving this "problem"... I wonder if he considered at some point make a contribution to stable open-source existing libraries like arrow that even claim inspiration on one of his projects for the API. What's not for humans on the arrow API? what are the arguments for basically start yet another time library from scratch?, why is making a contribution not an option? probably…

> what are the arguments for basically start yet another time library from scratch?

It's not exactly a time library from scratch, if you look at the amount of existing libraries it imports and the small code size (which is a good thing!). Why should he not offer a differently flavored API on top of existing parts? My impression is that most of these libs start with a strong idea what the API should be like, so large changes there are unlikely to happen.

Re: Maya – Python Datetimes for Humans

#100

Post by thrownblown »

masklinn wrote: post #54
etanol wrote: post #30

Not to undermine its merit, but most of the dirty work and heavy lifting is done by its dependencies: https://github.com/kennethreitz/maya/blob/d57a78c6bc6b5295f7... And i18n support in humanize is a bit lacking, as it only translates to French, Korean and Russian. Given that most of the translations needed to render human dates can be found in the CLDR database, maintaining their own looks like a bit of a wasted eff…

> Given that most of the translations needed to render human dates can be found in the CLDR database, maintaining their own looks like a bit of a wasted effort. You still need to parse the CLDR (the formats are pretty wonky) and provide APIs for its functions. Of course that's what Babel ( http://babel.pocoo.org ) does.

and here I thought babel was for es2015
Post reply on HN