Repository navigation
datetime and sub-second resolution plotting #10073
Description
Bug report
Bug summary
When plotting short (sub-second) time intervals, issues with tick labels and tick locations can be observed, and even the plot frames start looking jagged.
Code for reproduction
import datetime as pydt
import matplotlib.pyplot as plt
fig, axes = plt.subplots(nrows=7, ncols=1, figsize=(6, 10))
for i, ut in enumerate([60*1e6, 1e6, 1e5, 1e4, 1e3, 100, 10]):
td = pydt.timedelta(microseconds=ut)
dti = [pydt.datetime(2017, 12, 21, 12, 2, 59, 999922),
pydt.datetime(2017, 12, 21, 12, 2, 59, 999922) + td]
axes[i].plot(dti, [1, 1])
axes[i].set_title('delta t = {}'.format(td), position=(0.5, 0.4))
for l in axes[i].xaxis.get_majorticklabels():
l.set_rotation(45)
l.set_horizontalalignment('right')
plt.tight_layout()Actual outcome
Expected outcome
Investigation results
The underlying issue is MPL's internal datetime representation as a float: time in days since 0001-01-01 UTC, plus 1. While microsecond resolution is supported by datetime (and also by the AutoDateLocator and AutoDateFormatter), the floats lose actual microsecond precision after some years (in the order of 300 years). It is simply not possible to obtain microsecond resolution plots, with datetimes around today, without changing the internal time representation.
The workaround is: if you need microsecond resolution plots, shift your datetimes. Using year 1 instead of the current year will give highest precision. The default tick labels won't show the year anyway.
Perhaps this limitation & workaround could be placed somewhere in the documentation?
To make this work even better, I'd also like to suggest some small changes to the code (in dates._from_ordinalf()). Pull request will follow shortly.
Activity
jklymak commented on Dec 21, 2017
This may be a documentation issue, though I'm pretty sure the docs are clear that dates are handled by converting to float days since 0001. If you could find where you expected this information to be presented so its more discoverable, that would be great.
Perhaps a warning could be concocted when the floating point limit is being reached?
But fundamentally, I am not sure why we want datetime to be handling sub-second labelling. Yes, I know theoretically it does, but as you've shown, it doesn't do so very well. You are surely going to have less than a few seconds of data in the plot, and the proper format is floating point seconds. I'd be skeptical about anything that made the date handling more complicated.
nmartensen commented on Dec 22, 2017
The information on how the dates are handled is clear and discoverable. It still took me several hours to figure out the implication, namely that microsecond resolution does not work well with dates around today. Making this explicit is what I'm proposing (see PR).
Thanks for your suggestion to use floating point seconds. I've also included this.
nmartensen commented on Jan 21, 2018
fix is #10076