Great job, Mr. Reitz. I think I will use this in every project from now on. Thanks!
Maya – Python Datetimes for Humans
81–90 of 180 posts
Re: Maya – Python Datetimes for Humans
#82Awesome! 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…
How would you serialize that range to, for example, ISO8601?
Excellent question. ISO 8601 has features to encode time intervals ( https://en.wikipedia.org/wiki/ISO_8601#Time_intervals ).
If that's too verbose, and we only need to represent integer intervals, one could store a truncated representation, where the omitted parts mean "any" (like * in cron). For example, `2016-11` could mean the entire month of November.
But those are just ideas for the representation. The important feature is that not all objects are precise points in time, but may be a block/interval/range.
Re: Maya – Python Datetimes for Humans
#83Awesome! 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…
Honestly I feel like it would be easier to just have the "precision" of a date/time be adjustable. Just off the top of my head, ISO8601 is already in the right order, just letting users "leave off" anything that's not important and then having a library interpret those "partial dates" as a range internally so it's easy to check identity or if one date is "in" another.
That's exactly what I meant. Omitted parts should not be treated as zeroes, but as "any".
Re: Maya – Python Datetimes for Humans
#84I'm competent with strptime(), but this looks really nice:
# Automatically parse datetime strings and generate naive datetimes.
>>> scraped = '2016-12-16 18:23:45.423992+00:00'
>>> maya.parse(scraped).datetime(to_timezone='US/Eastern', naive=True)
datetime.datetime(2016, 12, 16, 13, 23, 45, 423992)
Re: Maya – Python Datetimes for Humans
#85Kenneth Reitz is a testament to how important good interfaces are in the developer community. There are literally 0 interesting things in the code (all dependency driven, https://git.io/v15i3). It does have a nice interface and because of this it will probably become one of the more popular python datetime libs.
Re: Maya – Python Datetimes for Humans
#86I'm competent with strptime(), but this looks really nice: # Automatically parse datetime strings and generate naive datetimes. >>> scraped = '2016-12-16 18:23:45.423992+00:00' >>> maya.parse(scraped).datetime(to_timezone='US/Eastern', naive=True) datetime.datetime(2016, 12, 16, 13, 23, 45, 423992) I'm happy not to have to write formatting arguments to strptime() anymore. Do the other datetime libraries have similar…
Maya actually uses the dateutil.parser.parse function from dateutils under the hood, which as far as I remember is the most comprehensive such function among the typical python datetime libs.
Re: Maya – Python Datetimes for Humans
#87Earlier quoted context omitted.
Worrying about split effort makes most sense when the problem is large and the amount of effort dedicated to the problem is limited, or when there are network effects that come from having more people involved in the project. I don't think that applies here. This library is not going to divert much (any?) effort that could have improved other date-time libraries.
If you contribute to any open source project, you quickly learn code is only a small (yet important) part of the effort. Other stuff that are splitted: - attention; - visibility; - pull requests; - documentation edits; - bug reports; - installs (and hence testing on the field); - compatibility layers; - compatible tooling; - 3rd party tutorials, snippets and examples; - help from integrators; Now if you don't have an…
Have a look at the code [1]. There's maybe 20 lines of actual logic in there.
Even taking all of what you mentioned into account, it's still not more than a single afternoon.
I agree with you in general, splintering in open source is a real problem worth tackling, but this is just not a case where it makes any sense to worry about that.
[1]: https://github.com/kennethreitz/maya/blob/master/maya.py
Re: Maya – Python Datetimes for Humans
#88Earlier 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…
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, times for religious services, lots of times are relative to local time, which itself is subject to change against UTC (sometimes predictable, sometimes not, the government gets to update the timezone and the DST scheme arbitrarily). So only ever storing UTC and using local time purely for display isn't a sustainable one-size-fits-all option.
Re: Maya – Python Datetimes for Humans
#89I'm competent with strptime(), but this looks really nice: # Automatically parse datetime strings and generate naive datetimes. >>> scraped = '2016-12-16 18:23:45.423992+00:00' >>> maya.parse(scraped).datetime(to_timezone='US/Eastern', naive=True) datetime.datetime(2016, 12, 16, 13, 23, 45, 423992) I'm happy not to have to write formatting arguments to strptime() anymore. Do the other datetime libraries have similar…
Maya actually uses the dateutil.parser.parse function from dateutils under the hood, which as far as I remember is the most comprehensive such function among the typical python datetime libs.
Wow, I've been using datetime for years, without ever noticing the dateutil library. I'll use this from now on.
Re: Maya – Python Datetimes for Humans
#90Yeah.. datetime is one of the rare part of the Python API that I really hate using. It's just badly designed, e.g. simple things are hard and confusing.