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

111–120 of 180 posts

Re: Maya – Python Datetimes for Humans

#111

Post by NelsonMinar »

ianamartin wrote: post #105

I think its fascinating that the community has no consensus about a datetime library. A lot of Python is really solved. We don't argue about using requests (a not-coincidental example). If you're using Python, and you need to deal with http, you use requests. Everyone knows this. There are basically 3 platforms for web frameworks. Flask, Pyramid, and Django. Maybe we're a little more dissolute than C# or Ruby folks,…

Related: the datetime library in pretty much every language is terrible. The only one I've ever used that I remember not actively hating was MomentJS.

Python's history of time types was terrible, as well. Particularly the era when we just used tuples of length 8 or 9 that weren't timezone aware.

Re: Maya – Python Datetimes for Humans

#112

Post by masklinn »

appleflaxen wrote: post #76
masklinn wrote: post #57

Earlier quoted context omitted.

Except (2) doesn't necessarily work when events are local and you factor in timezone variations (both DST and actual TZ changes). There are classes of events where you're much better off with zoned local dates e.g. local meetings. Example: in early 2011, Samoa announced that on December 29th at midnight local they would switch their timezone offset from -11 to +13. Before that announcement (or at least before your ti…

I think the recommendation still holds. You want a meeting at 1100 local time. Meeting is stored for that time in UTC, on the correct date (before Samoa changed, we all understood what date you meant) Samoa changes the rules. The calendar doesn't change. This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify.

> You want a meeting at 1100 local time.

On a specific day.

> The calendar doesn't change.

Of course it does, you've stored a UTC datetime, the timezone database is updated, the UTC datetime now maps to the wrong time (and because Samoa changed its offset by 24h it actually maps to the wrong day entirely every single time).

> This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify.

* while Pacific/Apia is UTC-11, you create a meeting for January 5th at 11 local

* this is stored as 2012-01-05T22:00:00+0000

* tzinfo gets updated with Pacific/Apia at UTC+13

* your calendar now tells you your meeting is on January 6th at 11 local

* you're a day late

Re: Maya – Python Datetimes for Humans

#115

Post by AdamN »

BoppreH wrote: post #23

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…

This would need to be done in Python itself, not Maya. I'd be strongly in favor of it though.

Re: Maya – Python Datetimes for Humans

#116

Post by rch »

sametmax wrote: post #104
rch wrote: post #101

Earlier quoted context omitted.

Do either of those libraries have an equivalent to the 'slang time' feature?

Arrow does, and have more translations.

Looks to me like Maya is focused on colloquial strings, while Arrow aspires to be a full datetime replacement. They're complementary.

Maya could have been built to require Arrow, but it makes sense to avoid the dependency.

Re: Maya – Python Datetimes for Humans

#117

Post by tedunangst »

appleflaxen wrote: post #76
masklinn wrote: post #57

Earlier quoted context omitted.

Except (2) doesn't necessarily work when events are local and you factor in timezone variations (both DST and actual TZ changes). There are classes of events where you're much better off with zoned local dates e.g. local meetings. Example: in early 2011, Samoa announced that on December 29th at midnight local they would switch their timezone offset from -11 to +13. Before that announcement (or at least before your ti…

I think the recommendation still holds. You want a meeting at 1100 local time. Meeting is stored for that time in UTC, on the correct date (before Samoa changed, we all understood what date you meant) Samoa changes the rules. The calendar doesn't change. This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify.

Samoa did change the calendar. The local utc mapping changed. In order to update the stored database, you need to convert all times to local with the old mapping, then convert to utc again with the new mapping.

Re: Maya – Python Datetimes for Humans

#118

Post by bjacobel »

NelsonMinar wrote: post #111
ianamartin wrote: post #105

I think its fascinating that the community has no consensus about a datetime library. A lot of Python is really solved. We don't argue about using requests (a not-coincidental example). If you're using Python, and you need to deal with http, you use requests. Everyone knows this. There are basically 3 platforms for web frameworks. Flask, Pyramid, and Django. Maybe we're a little more dissolute than C# or Ruby folks,…

Related: the datetime library in pretty much every language is terrible. The only one I've ever used that I remember not actively hating was MomentJS. Python's history of time types was terrible, as well. Particularly the era when we just used tuples of length 8 or 9 that weren't timezone aware.

Funny that JavaScript would find community alignment on something (anything!) where Python can't. I guess that's a testament to the work of the Moment creators.

Re: Maya – Python Datetimes for Humans

#119

Post by masklinn »

NelsonMinar wrote: post #111
ianamartin wrote: post #105

I think its fascinating that the community has no consensus about a datetime library. A lot of Python is really solved. We don't argue about using requests (a not-coincidental example). If you're using Python, and you need to deal with http, you use requests. Everyone knows this. There are basically 3 platforms for web frameworks. Flask, Pyramid, and Django. Maybe we're a little more dissolute than C# or Ruby folks,…

Related: the datetime library in pretty much every language is terrible. The only one I've ever used that I remember not actively hating was MomentJS. Python's history of time types was terrible, as well. Particularly the era when we just used tuples of length 8 or 9 that weren't timezone aware.

> The only one I've ever used that I remember not actively hating was MomentJS.

Boy do we disagree. Between the mutable API, the fuzzy parsing, the lack of tz support and the yet-another-reinvention of date/time formatting DSL[0] moment was one of those things I'd rather have not had in my life.

[0] which, to add insult to injury, is really similar to but not quite compatible with the LDML's

Re: Maya – Python Datetimes for Humans

#120

Post by ak217 »

I like Kenneth's work, but "I wrote a new datetime library" is a cliche now. We have datetime, dateutil, pytz, babel, arrow, pendulum, delorean, a bunch of lesser known stuff, and now this. I have yet to see the need for anything but the first four.
Post reply on HN