-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
Date fixes #3947
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Date fixes #3947
Conversation
…triple-quote docstrings for consistency.) Signed-off-by: Paul G <p.ganssle@gmail.com>
Signed-off-by: Paul G <p.ganssle@gmail.com>
…or the moment. Signed-off-by: Paul G <p.ganssle@gmail.com>
…om `datetime`. Signed-off-by: Paul G <p.ganssle@gmail.com>
…nversion. Signed-off-by: Paul G <p.ganssle@gmail.com>
One thing to note is that in the current master branch, I'll have to look through what the results would be, but I'm wondering if it might be a good idea to set |
Signed-off-by: Paul G <p.ganssle@gmail.com>
…atplotlib#3896. Signed-off-by: Paul G <p.ganssle@gmail.com>
…ects. Signed-off-by: Paul G <p.ganssle@gmail.com>
Sorry these builds keep failing - I don't have my full normal set up at the moment and its a bit of a pain to set up the Windows builds, so I can't do much more than basic unit tests. I also don't have my normal linting set up. I'll try and get everything sorted soon and make sure it passes the build tests. |
Thanks for working on this. I think master branch is the right place for these changes. It looks like at least part of the problem is that the converted times are now coming out with a timezone attached to them. |
Signed-off-by: Paul G <p.ganssle@gmail.com>
Signed-off-by: Paul G <p.ganssle@gmail.com>
@pganssle It shouldn't be a pain to build on windows using https://github.com/jbmohler/matplotlib-winbuild . I'm paying attention to any gotcha's on that. |
@jbmohler Thanks for the info. I saw that, but I don't have Visual Studio installed on this computer and it seems I have to register with Microsoft to get it, which I'm not really interested in doing. I'll either bite the bullet and register or I'll set up a virtual linux container here, because at the moment I've got something rigged up with cygwin that seems to just be limping along. |
…till fail, but that's fine for now. Signed-off-by: Paul G <p.ganssle@gmail.com>
@pganssle I do not believe that you need to register for the express edition of 2008 (Python 2.7) or 2010 (Python 3.3/4). I think you cannot build 64 bit with the express edition. |
…ys between two points. Signed-off-by: Paul G <p.ganssle@gmail.com>
OK, so I've cleared up most of the problems with the build failing. One that still remains arises from the fact that I've actually changed the behavior of
|
…lta object. Signed-off-by: Paul G <p.ganssle@gmail.com>
…timedelta` object actually calculates those for us as is. Signed-off-by: Paul G <p.ganssle@gmail.com>
Signed-off-by: Paul G <p.ganssle@gmail.com>
…e date locator. Signed-off-by: Paul G <p.ganssle@gmail.com>
…vious versions. Signed-off-by: Paul G <pg@example.com>
Signed-off-by: Paul G <pg@example.com>
Signed-off-by: Paul G <pg@example.com>
@tacaswell Good call. Was thinking of it as an instance method, but it makes more sense to think of it as an alias to the static call anyway. |
…hen dateutil <= 2.3 Signed-off-by: Paul G <pg@example.com>
…en necessary. Signed-off-by: Paul G <pg@example.com>
By the way, I know I mentioned on the dev list that I was going to look into using numpy's Please let me know if it needs to be rebased or if you want me to squash some of these commits or whatever, or anything else I need to fix, I suppose. |
Thanks for the ping, this had fallen off my radar. @mdboom How is the expert dates? |
'1990-02-17 00:00:00+00:00', '1990-03-10 00:00:00+00:00', | ||
'1990-03-31 00:00:00+00:00', '1990-04-21 00:00:00+00:00', | ||
'1990-05-12 00:00:00+00:00'] | ||
[datetime.timedelta(days=141), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember talking about this before, but not the conclusion. Why is it OK that the tests were changed here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tacaswell It's an expected (minor) behavior change caused by an increase in the accuracy of the way marker locations are calculated. I think the change was in this commit; previously if the beginning and end dates were January 3rd, 2000 and June 10th, 2015, relativedelta
object returns (years=15, months=5, days=7)
, and when get_locator()
is called, it calculated the number of days between the dates assuming that the number of days per year is 365 and the number of days per month is 30, so the number of days calculated would be 5632 rather than the true value of 5637.
It's a small inaccuracy, but it's easy to fix by holding on to a timedelta
object and using that when calculating days from years or months. As a result, some of the date range calculations are slightly different (though not to a degree that anyone would really notice), so at least one of the tests had to be updated (I vaguely remember updating one that was around 3 months and one that was around 3 weeks).
(Oops, responded to this in the PR not the line)
|
||
Currently `datetime.datetime.strftime()` is not supported for | ||
years <= 1900 in Python 2.x and years <= 1000 in Python 3.x. This | ||
function extends this functionality to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This cuts off rather abruptly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch. I'll fix this a bit later this week.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does not matter, removed in favor of #3242's changes
@pganssle Two super minor comments. This look almost ready! |
@pganssle, this needs a rebase, and address @tacaswell 's two minor comments. |
This also needs a rebase. |
Can do. Just started a new job, so I had to sort moving and IP issues. No
|
I know how that goes, congratulations! On Thu, Jul 16, 2015, 6:46 AM Paul Ganssle notifications@github.com wrote:
|
This has major conflicts with the changes merged in #3242 |
Yes, I noticed this when trying to rebase this past weekend. Working on resolving the conflicts. |
@pganssle Ah, sorry didn't realize you were working on this! I just did the merge/conflict resolution and all the tests pass locally.... |
@tacaswell Oh, no problem if it works. I had done the rebase but couldn't get the tests to run on my laptop (Windows), so I was just trying to transfer it over to a linux virtual box to test it. If the tests pass then I'm fine with that. |
Here are some fixes to some of the problems discussed in Issue #2845. Sorry I worked off of the master branch.
I consolidated all the "magic numbers" into a central location so they are consistent and easy to update if necessary, and I updated the
to_ordinalf
andfrom_ordinalf
functions to usedatetime.timedelta
rather than deal with converting fractional days to datetime objects and vice versa.