Cftime vs. datetime64 time encoding issues with ACCESS-OM2-025 OMIP-2 run

COSIMA Ocean
1

When I load in data from the ACCESS-OM2-025 OMIP-2 cycle6 run using xr.open_dataset and the default time encoding the time is incorrect. Best illustrated with the following snippet:

file = '/g/data/ik11/outputs/access-om2-025/025deg_jra55_iaf_omip2_cycle6/output364/ocean/ocean_daily.nc'

# Open file using default time encoding (will use datetime64 if possible, otherwise cftime):
ds = xr.open_dataset(file)
print('First time, default: ' + str(ds.time[0].values) + ' (incorrect!!!)')

# Open file without decoding time, and decode it by hand:
ds2 = xr.open_dataset(file,decode_times=False)
time_decoded = [np.datetime64('0001-01-01') + np.timedelta64(int(x*86400),'s') for x in ds2.time.values]
print('First time, decoded by hand: ' + str(time_decoded[0]) + ' (correct!!!)')

Output:

First time, default: 2016-12-30T12:00:00.000000000 (incorrect!!!)
First time, decoded by hand: 2017-01-01T12:00:00 (correct!!!)

The error is coming from using the cftime decoding, as if I try to force it to use datetime64 (by adding use_cftime=False) it errors with the message

OutOfBoundsDatetime: Cannot cast 0001-01-01 00:00:00 to unit='ns' without overflow.

Has anyone encountered this before (I couldn’t find anything on a quick google)? I can obviously get around it by decoding the times by hand, but would be nice to know what the source is and a good solution.

2

Looks like because the reference time is year 1, it should be using the proleptic_gregorian calendar which extends leap years backwards. Instead, with the gregorian calendar it’s missing leap years (and seconds?) before 1582.

3

Very late to the party, but is this the same issue? Problems decoding time dimension for ACCESS-ESM-1.5 long runs