41–50 of 180 posts
1) Whenever dealing with users, use local tz.
2) Always save and manipulate in utc.Earlier quoted context omitted.
It does not: timezone (TZ) definitions are politicial, inaccurate, and stupid and non versioned. The problem with TZ is TZ in its core definition. 1) they always change: if you have not updated your TZ since 3 months they are probably inaccurate 2) your TZ definition maybe accurate but they may not have been applied for real in the concerned zone 3) you can have different local time for the same longitude 4) you can…
The TZ database has versions and you could at least in theory expose that at a higher level in libraries.
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.
that's why there's `maya.when('yesterday', timezone='US/Eastern')` :)
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…
It 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?
How does it differ from Arrow which was made several years ago? [1] [1] http://crsmithdev.com/arrow/
Or Pendulum. Which is kind of a better arrow: https://github.com/sdispater/pendulum
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…
I'm pretty sure that it's 23 because some time passed between keystrokes, so the delta was 23:59:50, and he only keeps the most significant digit. I had to do this exact thing yesterday for timetaco.com.
Python datetimes used with timezones, even UTC, are ridiculously slow and bloated. It's puzzling why this doesn't wrap np.datetime64 instead. Or wrap boost.datetime. There are many good options to claw some performance back so it's really head-scratch inducing that someone would recognize that stdlib datetime is a dog and then wrap it instead of scrapping it.
Earlier quoted context omitted.
I'm pretty sure that it's 23 because some time passed between keystrokes, so the delta was 23:59:50, and he only keeps the most significant digit. I had to do this exact thing yesterday for timetaco.com.
Shouldn't it be immutable? I'd expect this to be a default behaviour.
Earlier quoted context omitted.
He wishes the guy was the sort of guy who contributed to other projects rather than doing his own thing. But if he WAS that sort of guy we wouldn't have Requests. I thought you guys were supposed to be smart.
No, he doesn't: > For request, a full rewrite made sense because urllib sucked so much and we had no good alternatives.
Yes, he does.
He wishes Kenneth was not the same as the existing Kenneth. He emphasizes this with the "for once".
Kenneth went his own way with Requests, and everyone is better off for it. You do not want a guy with that track record abandoning his work patterns.
I say, let the man be.
Whining about "fracturing" in open source ignores those important things which makes progress possible; conflict, competition, and triumph.
I see the original comment as being little more than a "yeah, it's nice, but you know, we already formed a committee and working group to do this thing".
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…
I'm pretty sure that it's 23 because some time passed between keystrokes, so the delta was 23:59:50, and he only keeps the most significant digit. I had to do this exact thing yesterday for timetaco.com.