For discussion:

Handling dates works pretty well but still has some drawbacks.

Current state:

An axis can accept datetime.datetime, datetime.date, and numpy.datetime64 objects for plotting, and runs these through a unit-converter. The module was written before datetime64 had settled down, and originally did not support this, and is hence based around date time.datetime tools.

As a review, datetime.datetime has a resolution of 1 microsecond, and handles a range of years from "0001" to "9999". numpy.datetime64 has resolutions down to 10^{-18} seconds, but the timespan that it can resolve drops with resolution. Currently to get to 10^{-9} seconds, it has +/- 292 year resolution, and to get to microseconds (10^{-6}) it has +/- 2.9e5 years. There is no stricture against negative dates, and if 1-s resolution is adequate, it can span dates that exceed the known age of the universe (+/- 10^{11} years) (https://docs.scipy.org/doc/numpy/reference/arrays.datetime.html)

Conversion to float is done with date2num (and back from num2date) and currently does as days from an epoch of "0001-01-01" (plus one), so 2020-01-01 comes out to 737425 or so. Numpy flatting point have 52 bits of resolution, so a modern date has a resolution of 14 microseconds when represented as floating point number. This leads to resolution issues when the user zooms in or plots with too small a range: (See #7138, Example in #15008, is the root of #5963, #7139)

Currently conversion relies on datetime.to_ordinal, and hence we cannot accept dates outside of 0001 and 9999

Automatic Formatting is done with a formatter that is very verbose, and leads to labels that are overlapping

Suggestions

Change the epoch, or let it be variable.

This is implemented in #15008. I actually feel pretty strongly we should just change the default epoch to something sensible, and then allow the user to change to something else if they prefer, including the old epoch.

Don't rely on to_ordinal for float conversion.

Suggest we change to doing float conversion via numpy.datetim64 math instead of using to_ordinal. This will allow negative years, and years stretching into aeons. This will require some basic work on locators and formatters to support, but thats not too hard.

Note we will still need datetime in there somewhere because the Locators rely on dateutil.rrule. To get rrule to work on dates outside of 0001-9999, we can take advantage of the fact that the Gregorian calendar repeats itself every 400 years.

Do float conversion per-axis

This would mean the epoch could be chosen based on the data on the axis. The user would, however, lose an easy way to pass floats to the axis for plotting because they would not know how to do the conversion.

Change the default formatter to ConciseDateFormatter.

See #10841. How do we make the API transition (if we indeed want to?)