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

151–160 of 180 posts

Re: Maya – Python Datetimes for Humans

#151

Post by masklinn »

STRiDEX wrote: post #128
masklinn wrote: post #119

Earlier quoted context omitted.

> 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

I've used timezones with momentjs. http://momentjs.com/timezone/ Its great. The parsing also has a strict mode http://momentjs.com/docs/#/parsing/string-format/ When did you last use it? I love working with momentjs.

> I've used timezones with momentjs. http://momentjs.com/timezone/ Its great. The parsing also has a strict mode http://momentjs.com/docs/#/parsing/string-format/

Yes, relatively recent options or completely separate projects allow doing these things. Do you know what happens to options when the default behaviour looks like it works? They don't get used, and the original garbage remains.

> I love working with momentjs.

And as I wrote earlier, boy do we disagree.

Re: Maya – Python Datetimes for Humans

#152

Post by masklinn »

meltingwax wrote: post #135
masklinn wrote: post #55

Earlier quoted context omitted.

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

> When the mapping between a time_t and a "human readable format" (hours, minutes, seconds, etc) takes into account extra leap seconds.

I still don't understand what you mean.

> You could use time_t underneath, if that's what you really wanted to do.

Well you've got unix timestamp (UTC) which "skips" leap seconds but as a result is very easy to map to "human time", or you've got TAI[0] which includes leap seconds but doesn't allow dates in the future since you don't know where and when new leap seconds will be added long in advance, and now you need regular updates/permanent connectivity so you can remap TAI onto human time. And you need an NTP replacement, though I guess having a GPS unit in everything would do.

[0] and GPS time which is just TAI + 19s

Re: Maya – Python Datetimes for Humans

#153

Post by smallnamespace »

vegabook wrote: post #150
smallnamespace wrote: post #139

Earlier quoted context omitted.

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.

Quantlib has a relatively small set implemented:

https://github.com/lballabio/QuantLib/tree/master/ql/time/da...

Re: Maya – Python Datetimes for Humans

#154

Post by masklinn »

vacri wrote: post #138
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…

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'?

> Using one of the most extreme edge cases is not a good argument.

1. How is it not a good argument? It's an actual historical fact which is not yet 5 years old rather than some intellectual exercise, you can hardly go better than "this stuff happened not 5 years ago".

2. The only "extreme" part here is the magnitude of the drift, it's a clear example and demonstration of the issue.

> How often is Samoa going to 'jump sides'?

How is that relevant to the problem specifically and clearly existing? Does it matter if your calendar is 24h off or 6h off? Your system is FUBAR either way.

> or another small dateline-neighbour country

The dateline isn't even relevant, are you somehow trying to win a prize in missing the point?

Re: Maya – Python Datetimes for Humans

#155

Post by [deleted] »

tedmiston wrote: post #146
jasoncchild wrote: post #145

Earlier quoted context omitted.

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.

[deleted]

Re: Maya – Python Datetimes for Humans

#156

Post by robochat »

BoppreH wrote: post #149
jeffbr13 wrote: post #148

Earlier quoted context omitted.

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?

The pandas library has a period data type if you're looking for one.

Re: Maya – Python Datetimes for Humans

#158

Post by robochat »

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.

There is a library called udatetime that claims to be very fast at parsing RFC3339 https://github.com/freach/udatetime

Re: Maya – Python Datetimes for Humans

#159

Post by krick »

Uh, Arrow? I'm not a big fan of it, really, as I've seen it to break silently on some edge cases API is not totally awesome, but this one doesn't seem to be any better. Still not sure if I should use this or that or write one of my own.

Re: Maya – Python Datetimes for Humans

#160

Post by ianamartin »

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 point I was trying to make is that this is a hard problem. Not hard in the computational complexity way. It's not NP-complete.

It's hard because the expected output is not fully agreed about.

We don't know what we want, and we don't know how to get it. That goes for pretty much every programming language I know of.

It's a hard problem because we suck, as people.

Post reply on HN