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

141–150 of 180 posts

Re: Maya – Python Datetimes for Humans

#141

Post by guitarbill »

aangjie wrote: post #40
fnord123 wrote: post #33

Python datetimes used with timezones, even UTC, are ridiculously slow and bloated. It's puzzling why this doesn't wrap np.datetime64 instead. Or wrap boost.datetime. There are many good options to claw some performance back so it's really head-scratch inducing that someone would recognize that stdlib datetime is a dog and then wrap it instead of scrapping it.

> It's puzzling why this doesn't wrap np.datetime64 instead. Perhaps to avoid the numpy dependency. I've found numpy a bit heavy and wouldn't want to depend on it simply for the sake of some datetime syntax. May be boost.datetime or even numpy's implementantion on datetime, but that sounds like a lot of maintenance.

Agree, 100%. E.g. numpy in a virtual environment can be a real pain. Best case, it takes a bit longer to install. Worst case, it's on a system that's missing some OS specific dependencies. "Works for me" is not okay for stuff on PyPI.

Re: Maya – Python Datetimes for Humans

#142

Post by [deleted] »

Walkman wrote: post #131

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

[deleted]

Re: Maya – Python Datetimes for Humans

#143

Post by [deleted] »

Walkman wrote: post #131

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

[deleted]

Re: Maya – Python Datetimes for Humans

#144

Post by tedmiston »

Walkman wrote: post #131

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

Just wanted to remind you that the entire Node community depends on one 11-line module. Lines of code is still a pretty meaningless metric.

Re: Maya – Python Datetimes for Humans

#145

Post by jasoncchild »

tedmiston wrote: post #144
Walkman wrote: post #131

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

Just wanted to remind you that the entire Node community depends on one 11-line module. Lines of code is still a pretty meaningless metric.

Idk, pointing to issues like deep dependency within the Node community isn't the best argument. It's healthy to be skeptical of dependencies imo, especially in light of issues like the infamous left pad problem.

Re: Maya – Python Datetimes for Humans

#146

Post by tedmiston »

jasoncchild wrote: post #145
tedmiston wrote: post #144

Earlier quoted context omitted.

Just wanted to remind you that the entire Node community depends on one 11-line module. Lines of code is still a pretty meaningless metric.

Idk, pointing to issues like deep dependency within the Node community isn't the best argument. It's healthy to be skeptical of dependencies imo, especially in light of issues like the infamous left pad problem.

My comment wasn't about deep dependencies; it was about parent suggesting 200 lines is too few to be a legitimate library.

Re: Maya – Python Datetimes for Humans

#148

Post by jeffbr13 »

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…

Python already contains separate date and time objects for this purpose[1][2]!

[1]: https://docs.python.org/3/library/datetime.html#date-objects [2]: https://docs.python.org/3/library/datetime.html#time-objects

Re: Maya – Python Datetimes for Humans

#149

Post by BoppreH »

jeffbr13 wrote: post #148
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…

Python already contains separate date and time objects for this purpose[1][2]! [1]: https://docs.python.org/3/library/datetime.html#date-objects [2]: https://docs.python.org/3/library/datetime.html#time-objects

I think that would only work for day long ranges. What if I want the events that happened in the last hour, or that are scheduled for May?

Re: Maya – Python Datetimes for Humans

#150

Post by vegabook »

smallnamespace wrote: post #139
dom0 wrote: post #96

Earlier quoted context omitted.

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…

I've personally re-implemented bond daycount for multiple markets several times at different shops. Maybe quantlib has this? Have never been allowed to use it.
Post reply on HN