`num2date` and `date2num` in `time.py` inconsistent with Matplotlib's versions

[pittwolfe]

num2date and date2num are implemented in time.py to save the user from having to import Matplotlib. However, the functions in time.py do not, in general, produce the same results as Matplotlib's versions. This is due to Matplotlib using the default epoch of Jan 1, 1970, while the toordinal and from fromordinal datatime methods uses Jan 1, 0001 as the epoch. Thus, ttide.time.num2date(1) produces datetime.datetime(1, 1, 1, 0, 0) while matplotlib.dates.num2date(1) produces datetime.datetime(1970, 1, 2, 0, 0, tzinfo=datetime.timezone.utc). Further, ttide.time.num2date does not accept non-positive arguments while matplotlib.dates.num2date does.

Since the docstring lists stime as being "in matplotlib_datenum format", someone using the stime argument to ttide.t_tide.t_tide will likely use matplotlib to generate the stime argument. Unless they know to change Matplotlib's default epoch before calling, there will be a large disagreement between what the user thinks stime represents and what t_tide thinks stime represents. Changing Matplotlib's default epoch on the fly is tricky, since this must be done before any calls to the date routines (i.e., immediately after import).

Not sure what the best solution is.

• One option would be to (perhaps optionally) revert to Matplotlib's version of these two functions. This would, of course, require the user to have Matplotlib. This is probably not too much of a burden since most users likely already have it.
• Another option would be to adjust ttide's the default epoch to match Matplotlib's, although this might cause trouble if someone changes their Matplotlib's epoch.
• A final option would be to be very specific about ttide's default epoch in the documentation.

I've held off on implementing a fix and submitting a pull request since I'm not sure what the best way forward is.

(Edited to fix typos.)

[moflaher]

A while ago Matplotlib changed the default epoch from Jan 1, 1970 to Jan 1, 0001 which is the source of this issue.

I will take a look at this, and see if what the best way to move forward is.
Thanks for bringing it to my attention.

[pittwolfe]

The current documentation gives 1970-01-01 as the default epoch, so perhaps they changed it back. If this sort of thing happens regularly, maybe the best solution is to check if Matplotlib is imported and query the current default epoch if so. Otherwise, go with some sensible default. This would allow the user to continue to avoid importing Matplotlib if they wish.