Extract the existing code from `datestr`.
Details
Diff Detail
- Repository
- rHG Mercurial
- Lint
Lint Skipped - Unit
Unit Tests Skipped
Event Timeline
Forget about my comment on the commit message, I was fooled by phabricator
Did you make one? I only see the two inline ones.
mercurial/util.py | ||
---|---|---|
1898 | I think usually Mercurial dates as passed around as tuples everywhere, so I decided to maintain that convention. |
mercurial/util.py | ||
---|---|---|
1862 | This function makes me really nervous, because it's a naive datetime rather than a tz-aware datetime. Could we do better about preserving the exact point-in-time value of the tz-aware time information? ("no" is a possible answer here, but I'd really like to know why we're not storing the zone offset in the datetime object.) |
mercurial/util.py | ||
---|---|---|
1862 | Hm, good question. I only do that because that's what the earlier code did -- that change dates from 87c6ad2251d8703d7f16d51e99e3d1c040f0be49, I think. |
mercurial/util.py | ||
---|---|---|
1862 | 87c6ad2251d8703d7f16d51e99e3d1c040f0be49 -- it linkifies if you don't use backtics, apparently |
mercurial/util.py | ||
---|---|---|
1862 | So, having reflected on this a bit: I'm too wary of the naive datetime. I think the easiest fix for this would be for us to have our own datetime.tzinfo implementation and then include that when we construct the datetime so we don't lose the zone offset information. |
Usually doc-string start with a lowercase letter in Mercurial code