This may be a good place to use theraise ... from e functionality of python3 (https://www.python.org/dev/peps/pep-3134/)

try:ticks= [vmin.astimezone(self.tz)]exceptValueErrorasE:raiseValueError()fromE

OH, Cool, didn't know about that. I'll do soon.

This is moot if we drop py3.5?

ah, this is targetted at 3.0.x so have to support 3.5 still.

Yep... Could milestone 3.1 if you prefer.

Why are you usingpytz for this? Tests withpytz are just to ensurematplotlib iscompatible withpytz, but this is a general functionality test. It's better to usedateutil.tz, which is not conditional onpytz installation.

The original bug report was pytz, and pytz doesn't work if the code is not as written in the PR. i.e. I needed to test pytz to get the PR to work, so it makes sense to test it here...

Is it not possible to reproduce the bug withdateutil.tz? Just because the reporter usedpytz doesn't mean you can't create an MWE without that dependency.

Just checked, the original bug is also present when you usedateutil.tz, with the original MWE now (more accurately in this case):

importmatplotlib.pyplotaspltfromdateutilimporttzfromdatetimeimportdatetime,timedeltax= [datetime(2010,1,1,tzinfo=tz.gettz('America/New_York'))+timedelta(i)foriinrange(2000)]plt.plot(x, [0]*len(x));

@pganssle : the way that tz info was put in before was to dovmin.replace(year=ymin, **self.replaced), butpytz doesn't work properly (at all) withreplace. So we need a test with pytz to test that this code works.

To be honest, we roundtrip most dates (datetime-> ordinal -> datetime) so the fact that pytz doesn't do the right thing w/tzinfo isn't that big a deal practically, but it would be nice if it worked.

I guess we could add another test that doesn't use pytz, but I think pytz should be tested on this code path.

replace(tzinfo=tz) andastimezone(tz) do two very different things.

If you think of time zones as units for datetimes,replace(tzinfo=tz) is like getting a value that says "1 ft", scratching off the "ft" and adding "m" to get "1m".astimezone(tz) is like getting something that says 1ft and converting it to meters to get0.3m.

Generally speaking,replace is used if you know that the local portion of the datetime is correct and want to say what time zone it's in.astimezone is used if you know that the absolute time represented by the datetime is correct and you want to convert it to a different local time.

In Python >=3.6,astimezone can be used on naive datetimes, but what that does is that it interprets the naive datetime aslocal time, and converts that to the time zone of interest. What that means is that if you are in Tokyo and give this a naive datetime likedatetime(2018, 1, 1) and haveYearLocator(tz=tz.gettz("America/New_York"), that's going to get converted to2017-12-31 10:00:00-05:00, which is probably not what you wanted.

pytz doesn't work properly (at all) with replace. So we need a test with pytz to test that this code works.

Also, I'll note that I'mwell aware of the limitations ofpytz.

I think probably it's best to use two tests, one withpytz (skipped ifpytz is not present) and one withdateutil. If you intend for the interface to look the same, you can likely parametrize the test function with a conditional skip onpytz.

Debug print?

Debug print?

Is this acutally different from he above cases?

Ummm, hmmm, not sure this was properly tested....