TimeConverter.reltime with time_origin = np.timedelta64 sensitive to precision

[VeckoTheGecko]

Parcels version

master

Description

The internals of TimeConverter with np.timedelta64 assumes that the precision is in seconds, when that might not actually be the case. Hence np.timedelta64(1, "D") - 1 gives 0 when in reality it should be treated in seconds all the way.

What would be a suitable precision for the object? I assume nanoseconds and then convert to float seconds for output?

Code sample

import cftime
import numpy as np

from parcels.tools.converters import TimeConverter, _get_cftime_datetimes

DAY = 24 * 60 * 60

def test_TimeConverter_timedelta64_float():
    tc = TimeConverter(np.timedelta64(0, "s"))
    assert tc.reltime(1 * DAY) == 1 * DAY

    tc = TimeConverter(np.timedelta64(0, "D"))
    assert tc.reltime(1 * DAY) == 1 * DAY

________________________________________________ test_TimeConverter_timedelta64_float _________________________________________________

    def test_TimeConverter_timedelta64_float():
        tc = TimeConverter(np.timedelta64(0, "s"))
        assert tc.reltime(1 * DAY) == 1 * DAY
    
        tc = TimeConverter(np.timedelta64(0, "D"))
>       assert tc.reltime(1 * DAY) == 1 * DAY
E       assert np.float64(7464960000.0) == (1 * 86400)
E        +  where np.float64(7464960000.0) = reltime((1 * 86400))
E        +    where reltime = 0 days.reltime

tests/tools/test_converters.py:24: AssertionError
======================================================= short test summary info =======================================================
FAILED tests/tools/test_converters.py::test_TimeConverter_timedelta64_float - assert np.float64(7464960000.0) == (1 * 86400)

[erikvansebille]

Yes, agree that this should be fixed

[VeckoTheGecko]

To be clear, I don't think think this bug is really encountered in production due to how the TimeConverter class is used. Regardless, I think this would be good to implement for robustness