You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?)
The text was updated successfully, but these errors were encountered:
For discussion:
Handling dates works pretty well but still has some drawbacks.
Current state:
An axis can accept
datetime.datetime
,datetime.date
, andnumpy.datetime64
objects for plotting, and runs these through a unit-converter. The module was written beforedatetime64
had settled down, and originally did not support this, and is hence based arounddate 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 fromnum2date
) 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 9999Automatic 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 ondateutil.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?)
The text was updated successfully, but these errors were encountered: