[offtopic] I do not like the "for humans" thing. What could it be for instead? for kangaroos or giraffes?
Popo: An Artisinal Handcrafted Curated Simple-yet-Powerful Library (for Waterfowl). By L'Wren Scott.
Maya – Python Datetimes for Humans
71–80 of 180 posts
Re: Maya – Python Datetimes for Humans
#72It is heartbreaking to see such a contributor like Kenneth Reitz in conferences. I really enjoy using Kenneth Reitz's creation : I would like to see him smile. He is probably in the top 10% of the developers, he does not profit of his talent as much as an idiot that just code shit. When I sample over the vast majority of free software coder I know (100s) over the non free one (~same) and I compare the wealth/recognit…
Do I look unhappy at conferences or something?
Yeah, why can't we ever get you to smile, go for walks, take creative photographs of the host city, crack jokes, host people in your AirBnb to tell stories of science and spirit? I mean jeez.
You are SO consumed with FOSS that you don't even make music. Or collect art. Or work on your photography. Or write about theories of mind and mental health issues. Or anything!
Re: Maya – Python Datetimes for Humans
#73Earlier quoted context omitted.
Do I look unhappy at conferences or something?
At pycon montréal you were looking a tad tired. Maybe I mistook jetlag for something else?
Something else being a void within his soul, representative of 'something rotten at the heart of programming'?
That's quite a leap to make from seeing someone tired.
Re: Maya – Python Datetimes for Humans
#74What's up buddy?
My only real question:
> rand_day = maya.when('2011-02-07', timezone='US/Eastern')
This returning an object representing a DateTime on the 6th (in UTC time) strikes me as perhaps "not for humans."
If I just see that line casually, I think I expect to get a Date and for it to be the 7th.
It looks like, in order to get this (arguably expected) object, I need to take the resulting MayaDT epoch and run its `datetime` method, passing naive=True?
And I also see that _tz can only ever be pytz.timezone('UTC') - is this the result of some belief that timezones are illusions or something? :-)
For a while, I have kinda thought that timezones foment a confused mental model of time and teamwork. I prefer to think in terms of the astronomy - it's not actually a different time anywhere else, it's just that the sun is at a different position relative to the rest of the earth (and thus, ones faraway teammates and loved ones).
Anyway, thanks for yet another set of interesting ideas. Hope you are well.
Re: Maya – Python Datetimes for Humans
#75I 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…
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 any very good alternatives, it's good : you want to steal that from them. But when you DO have good existing projects, then those are the bread and butter of their success.
Now I know it's way harder to contribute to something than roll you own. I know that's it's also more fun to roll your own. And there is the ego at play as well.
I understand all that, and I respect Kenneth as a professional. But I don't think it's a good call on his part here.
It is espacially true for him, because he now have such a good rep in the Python community that everything he does get under the spotlight.
Re: Maya – Python Datetimes for Humans
#76I 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.
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.
Re: Maya – Python Datetimes for Humans
#77Awesome! 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?
Re: Maya – Python Datetimes for Humans
#78Earlier 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 suppose due to DST, the same clock time on the next calendar date might not exist or be ambiguous.
Re: Maya – Python Datetimes for Humans
#79Awesome! 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.
Re: Maya – Python Datetimes for Humans
#80Awesome! 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?
From wiki: ISO8601 has four ways to express a time interval:
1. Start and end, such as "2007-03-01T13:00:00Z/2008-05-11T15:30:00Z".
2. Start and duration, such as "2007-03-01T13:00:00Z/P1Y2M10DT2H30M"
3. Duration and end, such as "P1Y2M10DT2H30M/2008-05-11T15:30:00Z"
4. Duration only, such as "P1Y2M10DT2H30M", with additional context information