DOC: improve removal for julian dates [ci doc] #26887
Conversation
There was a problem hiding this comment.
I find the two last sentences quite unsettling:
where some care needs to be taken with the accuracy of the
timedelta64. Given the various
definitions of Julian date, users should exercise caution using these values.
If the replacement was just a simple „use this instead“, I‘d be all for it. But with the additions I feel not confident that I could use it. I‘m inclined to say, let‘s not bother with explaining a replacement, if it‘s not straight forward. I don‘t think many users have used Julian dates after all.
|
I think we should say something to allow users to calculate this themselves, though I guess they could look at the source code. I've double checked that our definition matches with Wikipedia's, and link them. I've also changed it to "Matplotlib was using EPOCH=..." to make it clear that is a choice, and link out to Wikipedia if people need it. |
eae20da to
d69ace9
Compare
| (date - np.datetime64(EPOCH)) / np.timedelta64(1, 'D')``. Conversely, a Julian | ||
| date was converted to datetime as ``date = np.timedelta64(int(jdate * 24 * | ||
| 3600), 's') + np.datetime64(EPOCH)``. Matplotlib was using | ||
| ``EPOCH='-4713-11-24T12:00'`` so that 2000-01-01 at 12:00 is 2_451_545.0 (see |
There was a problem hiding this comment.
| ``EPOCH='-4713-11-24T12:00'`` so that 2000-01-01 at 12:00 is 2_451_545.0 (see | |
| ``EPOCH='-4713-11-24T12:00'`` so that 2000-01-01 at 12:00 is ``2_451_545.0`` (see |
possibly to clarify that it is a "Python float".
But clearly an improvement to me.
The removal notice could state the conversions since they are one-liners. #26852
PR summary
PR checklist