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

21–30 of 180 posts

Re: Maya – Python Datetimes for Humans

#21

Post by dom0 »

> Datetimes are a headache to deal with in Python, especially when dealing with timezones, especially when dealing with different machines with different locales.

Anything with date/time calculations is always a pain, probably doesn't really have much to do with the library/language itself, but that the abstraction level that's used (and typically used in other libraries) means that the complexities of calendar and time systems are sprinkled all over application code.

I do have to notice here that always using UTC is not always the right thing to do. For example, evaluating rrules in UTC is rather error-prone (DST).

Re: Maya – Python Datetimes for Humans

#23

Post by BoppreH »

Awesome! 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 install on Windows, so I opened an issue at https://github.com/kennethreitz/maya/issues/10

Re: Maya – Python Datetimes for Humans

#24

Post by ergo14 »

KODeKarnage wrote: post #20
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…

Who wishes that Requests didnt exist? That guy!!! ^^^^^^^

You comment makes no sense...

Re: Maya – Python Datetimes for Humans

#27

Post by duncanawoods »

krautsourced wrote: post #11

I wonder if the naming isn't a bit unfortunate, seeing that Maya is one of the major 3d packages out there and googling for Maya and Python will almost always lead there (also, not sure whether Autodesk might object...)

Yep. Picking cute short brand names for libraries as though they were startups clutters up the namespace of programmer's conversational language causing ambiguity and obfuscation. It would make life easier if we adopted an informal naming convention for small libraries e.g. . Lang is useful when libraries get ported so you get e.g. PyMayaTime, GoMayaTime etc. Still sounds cute but you know what its for when you pick up someone else's code and its easy to google.

Re: Maya – Python Datetimes for Humans

#28

Post by agumonkey »

krautsourced wrote: post #11

I wonder if the naming isn't a bit unfortunate, seeing that Maya is one of the major 3d packages out there and googling for Maya and Python will almost always lead there (also, not sure whether Autodesk might object...)

Years ago Maya had Python, now Python has Maya. The circle is complete.

ps: note that the Maya in Alias Wavefront (now Autodesk but nope) Maya is not that Maya, it's Sanskrit for illusion, which is what Maya was all about considering what it did to your dollars.

Re: Maya – Python Datetimes for Humans

#30

Post by etanol »

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

Reference:

http://cldr.unicode.org/

Post reply on HN