René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Discuss: Date handling issues and ideas","articleBody":"For discussion:\r\n\r\nHandling dates works pretty well but still has some drawbacks.\r\n\r\n## Current state:\r\n\r\nAn 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.  \r\n\r\nAs 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)\r\n\r\n\r\nConversion 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)\r\n\r\nCurrently conversion relies on `datetime.to_ordinal`, and hence we cannot accept dates outside of 0001 and 9999\r\n\r\nAutomatic Formatting is done with a formatter that is very verbose, and leads to labels that are overlapping\r\n\r\n## Suggestions\r\n\r\n### Change the epoch, or let it be variable.  \r\n\r\nThis 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.\r\n\r\n### Don't rely on `to_ordinal` for float conversion.\r\n\r\nSuggest 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.   \r\n\r\nNote 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.  \r\n\r\n### Do float conversion per-axis\r\n\r\nThis 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.  \r\n\r\n### Change the default formatter to ConciseDateFormatter.  \r\n\r\nSee #10841.  How do we make the API transition (if we indeed want to?)","author":{"url":"https://github.com/jklymak","@type":"Person","name":"jklymak"},"datePublished":"2019-08-09T17:33:27.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":1},"url":"https://github.com/15018/matplotlib/issues/15018"}