MAmaxerickson·Nov 19, 2017
Possibly https://github.com/kennethreitz/maya
In Luxon – A library for working with dates and times in JSkennethreitz
maya
Python2016–2017
kennethreitz / maya
maya
Datetimes for Humans™
8Distinct people
9Mentions
1Explicit recommenders
3.4KGitHub stars
What to know before exploring
What it is
Datetimes for Humans™
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
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…
niftich used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month9 dated mentions
Observed mentions: 2016-12-16 01:18:51 UTC to 2017-11-19 16:51:56 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| Dec 2016 | 2016-12-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 8 | 2 | 6 |
| Jan 2017 | 2017-01-01 00:00:00 UTC | 2017-02-01 00:00:00 UTC | 0 | 0 | 0 |
| Feb 2017 | 2017-02-01 00:00:00 UTC | 2017-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2017 | 2017-03-01 00:00:00 UTC | 2017-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2017 | 2017-04-01 00:00:00 UTC | 2017-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2017 | 2017-05-01 00:00:00 UTC | 2017-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2017 | 2017-06-01 00:00:00 UTC | 2017-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2017 | 2017-07-01 00:00:00 UTC | 2017-08-01 00:00:00 UTC | 0 | 0 | 0 |
| Aug 2017 | 2017-08-01 00:00:00 UTC | 2017-09-01 00:00:00 UTC | 0 | 0 | 0 |
| Sep 2017 | 2017-09-01 00:00:00 UTC | 2017-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2017 | 2017-10-01 00:00:00 UTC | 2017-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2017 | 2017-11-01 00:00:00 UTC | 2017-12-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
9 sourcesImportant note from the comments in that issue: Kenneth says that Maya is only tested on Python 2.7 so far. Python 3 support is coming later.
https://github.com/kennethreitz/maya/issues/10#issuecomment-...
In Maya – Python Datetimes for HumansThe 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')
<MayaDT epoch=1481919067.23>
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 normalize
Read the rest
s 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
Have a look at the code [1]. There's maybe 20 lines of actual logic in there.
Even taking all of what you mentioned into account, it's still not more than a single afternoon.
I agree with you in general, splintering in open source is a real problem worth tackling, but this is just not a case where it makes any sense to worry about that.
[1]: https://github.com/kennethreitz/maya/blob/master/maya.py
In Maya – Python Datetimes for HumansNot 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 effort.
Reference:
http://cldr.unicode.org/
In Maya – Python Datetimes for HumansAwesome! Timekeeping is hard and I'm glad we now have one more tool do deal with it.
One thing that is bothering me is that when you ask for `maya.when('tomorrow')`, or give only a date, you get back a timestamp with millisecond precision, representing 00:00 of that day. I understand this simplifies the implementation, but shouldn't `tomorrow` be a range, from 00:00 to 23:59?
Treating imprecise dates as ranges would allow for stuff like
# Did this event happen "yesterday" according to the US/Eastern time zone?
timestamp in maya.when('yesterday', to_timezone='US/Eastern')
# Get me all events that happened last Friday (UTC)
[event for event in events if event.time in maya.when('2016-12-16')]
Maybe I'm being naive, and there's a reason why this won't work, but this seems the way most humans deal with time.
PS: it failed to
Read the rest
install on Windows, so I opened an issue at https://github.com/kennethreitz/maya/issues/10
Maya – Python Datetimes for Humans
1 points · Open discussionThis doesn't seem to be a submission by the author himself, and the project is only two hours and five commits old, so 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')
<MayaDT epoch=1481919067.23>
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 midni
Read the rest
ght 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