Skip to content

Off-by-one bug in annual axis labels when localized time crosses year boundary #12675

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

Closed
paulgb opened this issue Oct 30, 2018 · 6 comments · Fixed by #12678
Closed

Off-by-one bug in annual axis labels when localized time crosses year boundary #12675

paulgb opened this issue Oct 30, 2018 · 6 comments · Fixed by #12678
Assignees
Milestone

Comments

@paulgb
Copy link

paulgb commented Oct 30, 2018

Bug report

Bug summary

When plotting dates with time zone information on the x-axis, under certain circumstances, the wrong year will be displayed as the label.

Code for reproduction

import matplotlib.pyplot as plt
import pytz
from datetime import datetime, timedelta

x = [datetime(2010, 1, 1, tzinfo=pytz.timezone('America/New_York')) + timedelta(i) for i in range(2000)]
plt.plot(x, [0] * len(x));

Actual outcome

The first label on the plot is 2009.

Expected outcome

The first label on the plot is 2010.

Matplotlib version

Built this morning from master. Also confirmed the issue on 3.0.0 and confirmed that 2.2.2 does not have the issue (or at least not with the reproduction steps I found.)

  • Operating system: Debian 7.11
  • Matplotlib version: from source
  • Matplotlib backend module://ipykernel.pylab.backend_inline
  • Python version: 3.7.0
  • Jupyter version (if applicable): 4.4.0
  • Other libraries: pytz 2018.5

I built matplotlib from source to verify that this bug affects master. The checks against 3.0.0 and 2.2.2 were done on a conda install of those versions and may have had different versions of pytz and jupyter.

@jklymak
Copy link
Member

jklymak commented Oct 30, 2018

OK, this bisects to 0337883 (#9801). Not sure why that causes this bug, but it is certainly a bad one.

@jklymak jklymak self-assigned this Oct 30, 2018
@jklymak jklymak added this to the v3.0.x milestone Oct 30, 2018
@ImportanceOfBeingErnest
Copy link
Member

A workaround is to set the interval_multiples to False.

plt.gca().xaxis.get_major_locator().interval_multiples = False

But that's sure not a sustainable solution.

I wonder if this goes deeper, because without the time zone it works fine.

@jklymak
Copy link
Member

jklymak commented Oct 30, 2018

Yeah, I think #9801 just made the real bug more apparent by changing the default interval_multiples

@jklymak
Copy link
Member

jklymak commented Oct 30, 2018

OK, this seems to be either a datetime bug or pytz bug?

import pytz
from datetime import datetime, timedelta, timezone
UTC = timezone.utc

date0 = datetime(2010, 1, 1, tzinfo=pytz.timezone('US/Pacific'))
print('date0    ', date0)
dateUTC = date0.astimezone(tz=UTC)
print('dateUTC  ', dateUTC)
dateLocal = dateUTC.astimezone(tz=pytz.timezone('US/Pacific'))
print('datelocal', dateLocal)

yields:

date0     2010-01-01 00:00:00-07:53
dateUTC   2010-01-01 07:53:00+00:00
datelocal 2009-12-31 23:53:00-08:00

@jklymak
Copy link
Member

jklymak commented Oct 30, 2018

Ah, OK, you can't do:

datetime(2010, 1, 1, tzinfo=pytz.timezone('America/New_York'))

but you can do:

datetime(2010, 1, 1).astimezone(pytz.timezone('America/New_York'))

Doing

date0 = datetime(2010, 1, 1, 0,0,0).astimezone(pytz.timezone('US/Pacific'))
print('date0    ', date0)
dateUTC = date0.astimezone(tz=UTC)
print('dateUTC  ', dateUTC)
dateLocal = dateUTC.astimezone(tz=pytz.timezone('US/Pacific'))
print('datelocal', dateLocal)

yields a good round trip..

date0     2010-01-01 00:00:00-08:00
dateUTC   2010-01-01 08:00:00+00:00
datelocal 2010-01-01 00:00:00-08:00

OTOH, the bug described above is still an issue...

@jklymak
Copy link
Member

jklymak commented Oct 30, 2018

OK, thanks for the bug report - there was a tz argument not being passed through. Fixed in #12678

@tacaswell tacaswell modified the milestones: v3.0.2, v3.0.3 Nov 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants