101–110 of 180 posts
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…
Earlier quoted context omitted.
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.
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…
Do either of those libraries have an equivalent to the 'slang time' feature?
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.
Earlier quoted context omitted.
I think the recommendation still holds. You want a meeting at 1100 local time. Meeting is stored for that time in UTC, on the correct date (before Samoa changed, we all understood what date you meant) Samoa changes the rules. The calendar doesn't change. This stuff is mind-bending, so I could be missing something, but a more detailed walk through your mental debugger might clarify.
Classic counter example: storing business hours. If the store/exchange opens at 8:00AM every weekday in Somethingania/Foocity, you want to store 8:00 and the name/reference of the timezone. Because the store/exchange will still open at 8:00AM local time, even across DST, government-mandated timezone changes etc (largely, I'm sure there are exceptions but for stock exchanges there definitely aren't). School times, tim…
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…
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…
I wonder if the naming isn't a bit unfortunate, seeing that Maya is one of the major 3d packages out there and googling for Maya and Python will almost always lead there (also, not sure whether Autodesk might object...)
Like "JodaTime" and "Golang"