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

51–60 of 180 posts

Re: Maya – Python Datetimes for Humans

#51

Post by SFJulie »

gdubya wrote: post #16
SFJulie wrote: post #6

It is heartbreaking to see such a contributor like Kenneth Reitz in conferences. I really enjoy using Kenneth Reitz's creation : I would like to see him smile. He is probably in the top 10% of the developers, he does not profit of his talent as much as an idiot that just code shit. When I sample over the vast majority of free software coder I know (100s) over the non free one (~same) and I compare the wealth/recognit…

Maybe some people value other things in life than social and wealth status?

Maybe, the value in code in production nowadays relies heavily on innovative code coming from free software that would not be done in R&D in most companies.

And while people use this code to make actual value in their companies, trying to code as you code in free software (doing correct documentation, testing, correct issues tracking, validating) is often leading to conflicts because of time to market.

Correct software takes time and an integrity that needs no excuses. Production software requires politics.

I think the IP laws are ripping the true innovators of their values.

And maybe people do not strive for recognition, but I see very few companies out there that will not use free software without even giving credits to the original authors.

And whatever your license is, the right 0 of any developers is to keep his/her name associated with their creations.

IP laws are broken they gives the most values not to the one who do but the one who have the money to sit on others shoulders without giving back.

Most software developers are like theater play writers that would not only stay poor while the people playing their creations not only get rich but also famous without giving but a small portion of what they earn or give credits. The giving back to free software is pity money, a drop in the ocean of the profits generated.

Authors' rights have become the tools to actually achieve what they were designed to avoid.

Re: Maya – Python Datetimes for Humans

#52

Post by StavrosK »

webmaven wrote: post #50
StavrosK wrote: post #43

Earlier quoted context omitted.

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.

Shouldn't it round up?

If it's 01:00:01, is it two hours?

Re: Maya – Python Datetimes for Humans

#53

Post by misnome »

Drdrdrq wrote: post #38
kenneth_reitz wrote: post #7

Earlier quoted context omitted.

that's why there's `maya.when('yesterday', timezone='US/Eastern')` :)

That's great, but why this then: >>> tomorrow = maya.when('tomorrow') >>> 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…

Why on earth is 'tomorrow' just +24 (local) hours. I'd expect it to be the next calendar date.

Re: Maya – Python Datetimes for Humans

#54

Post by masklinn »

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.

Re: Maya – Python Datetimes for Humans

#55

Post by masklinn »

meltingwax wrote: post #14

This is designed for programmers of user facing applications. For science and engineering, it does not address the problems, eg lack of leap seconds.

> For science and engineering, it does not address the problems, eg lack of leap seconds.

What do you mean by "lack of leap seconds"? A non-unix-timestamp-based time library?

Re: Maya – Python Datetimes for Humans

#57

Post by masklinn »

Drdrdrq wrote: post #41

I have found that no matter what language/platform I use, the one thing that is always supported is UNIX timestamp. That makes date+time operations much easier: 1) Whenever dealing with users, use local tz. 2) Always save and manipulate in utc.

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 timezone database has been updated), store as UTC a meeting in local Samoa time, and the user will miss their meeting by a day.

Of course storing a meeting on December 30th local would also have been fraught as there is no December 30th 2011 in Pacific/Apia but that is a common occurrence historically due to the unsynchronised julian/gregorian switches e.g. none of the dates between February 16th and February 28th 1923 (included) exist in Greece, and the US doesn't have a 9/11 in 1752.

Re: Maya – Python Datetimes for Humans

#58

Post by robochat »

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…

Right, there's arrow and pendulum and also http://delorean.readthedocs.io/en/latest/index.html plus the Datetime options offered by pandas and the numpy.datetime64 type. It gets to be pretty confusing particularly when you need to start transforming between the different types.

Re: Maya – Python Datetimes for Humans

#59

Post by daenney »

djrobstep wrote: post #45
crdoconnor wrote: post #22

Earlier quoted context omitted.

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

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.

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

Re: Maya – Python Datetimes for Humans

#60

Post by daenney »

Singletoned wrote: post #36
smegel wrote: post #4

Earlier quoted context omitted.

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?

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.

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.

Post reply on HN