121–130 of 180 posts
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...)
So this library would need to be installed as a separate name to be usable there.
Earlier quoted context omitted.
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.
Funny 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.
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 [2] https://news.ycombinator.com/item?id=12175369
Earlier quoted context omitted.
The TZ database has versions and you could at least in theory expose that at a higher level in libraries.
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.
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.
> You want a meeting at 1100 local time. On a specific day. > The calendar doesn't change. Of course it does, you've stored a UTC datetime, the timezone database is updated, the UTC datetime now maps to the wrong time (and because Samoa changed its offset by 24h it actually maps to the wrong day entirely every single time). > This stuff is mind-bending, so I could be missing something, but a more detailed walk throug…
The scheduling library should be more upfront about /what/ is being agreed to and force the user to pick.
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 of the first you store a precise UTC timestamp and drop the timezone (it's UTC).
In the case of the second you store /how/ to pick a UTC timestamp based on a time in a timezone.
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…
This would need to be done in Python itself, not Maya. I'd be strongly in favor of it though.
https://docs.python.org/3.5/reference/datamodel.html#object....
> Datetimes are a headache to deal with in Python, especially when dealing with timezones, especially when dealing with different machines with different locales. Anything with date/time calculations is always a pain, probably doesn't really have much to do with the library/language itself, but that the abstraction level that's used (and typically used in other libraries) means that the complexities of calendar and t…
Earlier quoted context omitted.
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 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
When did you last use it? I love working with momentjs.
But does it get DST correct. I haven't found any python time libraries that do.
A lot of effort has been put into getting DST right so I hope it will be what you are looking for.
Disclaimer: I am the author of Pendulum :-)
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.
Two very common examples: For a recurring scheduled event, "Same time tomorrow" may require adding 24, 23 or 25 hours to the UTC time, depending on the TZ.
The question "how many full days have elapsed between two timestamps?" may need to return 1 for 23.5 hour distance or 0 for 24.5 hour distance depending on the TZ.
I'd be so happy if we all could agree that a day always has 24 hours, but that doesn't seem likely any time soon.