Skip to content
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

Discuss: Date handling issues and ideas #15018

Closed
jklymak opened this issue Aug 9, 2019 · 1 comment
Closed

Discuss: Date handling issues and ideas #15018

jklymak opened this issue Aug 9, 2019 · 1 comment

Comments

@jklymak
Copy link
Member

jklymak commented Aug 9, 2019

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?)

@jklymak jklymak added this to the unassigned milestone Aug 9, 2019
@jklymak
Copy link
Member Author

jklymak commented Apr 30, 2020

Close this is largely done. Only outstanding is #17022, but that should be able to go in soon.

@jklymak jklymak closed this as completed Apr 30, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant