3 ms·
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
by ianamartin 10y ago
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, but that's pretty impressive considering how much we Python people like to roll our own.
The fact that there is real disagreement about this among ourselves about this particular issue says to me that this is more about the difficulty of the problem than it is anything else.
- NelsonMinar 10y agoRelated: 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.
- bjacobel 10y agoFunny 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.
- niftich 10y agoIt is. Datetime is an unpleasant problem domain, and Tim was active both on SO [1] and Github, arguably so much so that it was to the detriment of his health [2]. In the case of Moment, a little promotion went a very long way, and the community was eager to take what's given so they wouldn't have to think too much about datetime, and focus on debating how to arrange and design their applications instead. Moment's design is a testament to "let's not think too hard about datetime", and I mean that both as a compliment and a critique. [1] http://stackoverflow.com/users/272034/timrwood?tab=summary http://stackoverflow.com/users/272034/timrwood?tab=summary [2] https://news.ycombinator.com/item?id=12175369 https://news.ycombinator.com/item?id=12175369
- masklinn 10y ago> 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
- STRiDEX 10y agoI've used timezones with momentjs. http://momentjs.com/timezone/ http://momentjs.com/timezone/ Its great. The parsing also has a strict mode http://momentjs.com/docs/#/parsing/string-format/ http://momentjs.com/docs/#/parsing/string-format/ When did you last use it? I love working with momentjs.
- masklinn 10y ago> I've used timezones with momentjs. http://momentjs.com/timezone/ http://momentjs.com/timezone/ Its great. The parsing also has a strict mode http://momentjs.com/docs/#/parsing/string-format/ 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.
- ianamartin 10y agoThe 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.