num2date method not accurate for arrays

[jblarsen]

$ cat test_cftime.py 
import cftime
print(cftime.__version__)

units = 'seconds since 1970-01-01 00:00:00'
calendar = 'standard'
times_in = [1261440000.0, 1261440001.0, 1261440002.0, 1261440003.0,
            1261440004.0, 1261440005.0]
times_out = cftime.num2date(times_in, units, calendar)
print(times_out)
times_out = []
for time_in in times_in:
    times_out.append(cftime.num2date(time_in, units, calendar))
print(times_out)

$ python3 test_cftime.py 
1.1.0
[cftime.DatetimeGregorian(2009-12-22 00:00:00)
 cftime.DatetimeGregorian(2009-12-22 00:00:01)
 cftime.DatetimeGregorian(2009-12-22 00:00:02)
 cftime.DatetimeGregorian(2009-12-22 00:00:03)
 cftime.DatetimeGregorian(2009-12-22 00:00:04.18)
 cftime.DatetimeGregorian(2009-12-22 00:00:05.13)]
[cftime.DatetimeGregorian(2009-12-22 00:00:00), cftime.DatetimeGregorian(2009-12-22 00:00:01), cftime.DatetimeGregorian(2009-12-22 00:00:02), cftime.DatetimeGregorian(2009-12-22 00:00:03), cftime.DatetimeGregorian(2009-12-22 00:00:04), cftime.DatetimeGregorian(2009-12-22 00:00:05)]

I would expect the results to be identical and equal to the latter result.

I am running this on Ubuntu 18.04 with Python 3.6.9.

[jswhit]

cftime computations have an accuracy of about 100 ms. I see in your example errors of O(10) microseconds, which is within the stated error bounds.

[jblarsen]

Thanks for the reply. It seems to me that the error for 2009-12-22 00:00:05.18 is 180 milliseconds and not O(10) microseconds? But that is still around the error bounds that you mention.

For my purposes I can just round to nearest second:-)

[jswhit]

It is really microseconds - so perhaps that formatting is incorrect.

[jswhit]

pull request #146 fixes the microsecond formatting, and makes sure the num2date calculation work the same for scalars and arrays.

[jswhit]

Need to add your script to the test suite.

[jswhit]

PR #146 merged, closing now