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

131–140 of 180 posts

Re: Maya – Python Datetimes for Humans

#131

Post by Walkman »

This is a joke. The whole "library" is 200 lines, has 9 tests, Kenneth probably wrote it in a couple of hours. It is totally not necessary, because, there are a gazillion datetime libraries and still, this is on the front page?

Also:

    >>> dt = maya.now()
    >>> dt.datetime()
    datetime.datetime(2016, 12, 18, 19, 24, 50, 212663, tzinfo=)

    >>> dt.datetime('Europe/Budapest')
    datetime.datetime(2016, 12, 18, 20, 24, 50, 212663, tzinfo=)
I would not use it...

Re: Maya – Python Datetimes for Humans

#132

Post by sdoering »

robochat wrote: post #58
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.

Ohhhh thanks. Used delorean some years ago and still have a soft spot...

... nice to see it mentioned.

Re: Maya – Python Datetimes for Humans

#133

Post by foxhop »

My first commit to ago.py was 'Fri Jun 29 19:25:55 2012'.

    >>> import ago
    >>> import dateutil
    >>> ago.human(dateutil.parser.parse('Fri Jun 29 19:25:55 2012'))
    '4 years, 172 days ago'


 The current implementation is 66 lines of code including docstrings:
* https://bitbucket.org/russellballestrini/ago/src/tip/ago.py

* https://pypi.python.org/pypi/ago

Re: Maya – Python Datetimes for Humans

#134

Post by guitarbill »

jMyles wrote: post #74

What's up buddy? My only real question: > rand_day = maya.when('2011-02-07', timezone='US/Eastern') This returning an object representing a DateTime on the 6th (in UTC time) strikes me as perhaps "not for humans." If I just see that line casually, I think I expect to get a Date and for it to be the 7th. It looks like, in order to get this (arguably expected) object, I need to take the resulting MayaDT epoch and run i…

It's worth thinking of it the same as strings. Strings can have several encodings, e.g. ASCII, UTF-8 and a hundred others. These are external representation. You don't want to parse the string every time you have to deal with it, so you parse it and store it using (ideally) a single internal representation (e.g. UCS-2, UCS-4). Then, when you need to pass the string to something else, you encode again.

Same with dates. Instead of trying to deal with and store all possible representations (format, timezones, etc), you convert all dates to a single representation (hence UTC). When you need to output the date, encode it into whatever format and timezone you need.

It's much cleaner this way, because there's less chance you'll mix up representations. So the "for humans" part is more "for developers, which are also humans but like to pretend they aren't and never make mistakes".

Re: Maya – Python Datetimes for Humans

#135

Post by meltingwax »

masklinn wrote: post #55
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?

When the mapping between a time_t and a "human readable format" (hours, minutes, seconds, etc) takes into account extra leap seconds. You could use time_t underneath, if that's what you really wanted to do.

As my co-worker once put it, "time is a four letter word."

At the very least, there is a need for showing the occasional 61st second of a minute, and adding a time and timedelta where leap seconds is taken into account.

Re: Maya – Python Datetimes for Humans

#136

Post by guitarbill »

Stasis5001 wrote: post #123
nicpottier wrote: post #42

Earlier quoted context omitted.

Pretty sure pytz will hand you the appropriate timezone for a given date. There aren't version numbers after all but it can do the right thing based on when you say it is. There is some weird behaviour due to this when trying to get a timezone without an associated date as it doesn't default to now. Then again you probably have all sorts of DST bugs if you have places in your code that do that.

Pytz handles a certain class of funkiness in TZ changes, but not the one mentioned here. Consider, a user in footopia enters a datetime 3 months from now which is saved in UTC in your database. Then footopia changes their TZ definition. The only way you could get this right is if you also know when the datetime in the database was created. You would need to tell your datetime library the datetime and _when it was cre…

You'll never get this right, even if you had all of this info, because as mjevans points out[0] to make it work you need to know:

> P) The event is at a precise internationally recognized moment (better for co-ordination globally).

> R) The event is in local time (like a lunch date) and expected to remain colloquially fixed.

In the case you mention, it's somewhat arguable that the burden of changing the colloquially fixed dates (R) falls on the citizens of footopia, in the same way as changing the time of a purely mechanical clock also would. caveat emptor.

[0] https://news.ycombinator.com/item?id=13206671

Re: Maya – Python Datetimes for Humans

#137

Post by meltingwax »

bpicolo wrote: post #70
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.

Seems like your OS / clock source should always be the guy handling leap seconds. Why would a higher-level library do it? The cases are pretty rare that you'd want to think differently about leap seconds in higher level code.

Here's an example:

I have packets read from an instrument which are timestamped in seconds since 1980-01-06 (GPS Epoch). To compute each packet's proper datetime representation in TAI, I need add those seconds to 1980-01-06, and subtract the amount of leap seconds that occurred. The subtracting of leap seconds could be done automatically by a library. When a leap second is added, it will occur on the 61st second of the minute (second = :60). These times aren't supported by the datetime class.

Re: Maya – Python Datetimes for Humans

#138

Post by vacri »

masklinn wrote: post #57
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 ti…

Using one of the most extreme edge cases is not a good argument. How often is Samoa (or another small dateline-neighbour country) going to 'jump sides'?

Re: Maya – Python Datetimes for Humans

#139

Post by smallnamespace »

dom0 wrote: post #96
vegabook wrote: post #91

Earlier quoted context omitted.

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, subsecon…

Regarding recurrence rules specifically, I worked in the financial services industry and bonds and derivatives obviously recur (usually monthly) for decades.

Not only do you need to specify the precise dates of recurrences, but you also need to map time intervals to fractions of a year (e.g. if I owe you $1mm a year, is 'one month' equal to 1/12 of a year, or do I count the actual numer of days in between? What about leap days, etc.). Getting it wrong even slightly means you get all the cashflows wrong.

Welcome to the joy of 'day count conventions' [1] and 'date rolling' [2].

[1] https://en.wikipedia.org/wiki/Day_count_convention [2] https://en.wikipedia.org/wiki/Date_rolling

Funny thing is these have all probably be reimplemented from scratch at every single bank.

Re: Maya – Python Datetimes for Humans

#140

Post by tedmiston »

kenneth_reitz wrote: post #8
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…

Do I look unhappy at conferences or something?

You looked great at PyCon this year. Thanks for the requests stickers!
Post reply on HN