`process_cmip_data`: `_get_xr_cftime_kwargs` forces `use_cftime=True`, causing time coordinate to be decoded as dtype `object`

[rodaguayo]

In process_cmip_data (and other functions in gcm_climate.py), the helper _get_xr_cftime_kwargs() is called unconditionally when opening NetCDF files:

with xr.open_dataset(fpath_temp, **_get_xr_cftime_kwargs()) as tempds, \
        xr.open_dataset(fpath_precip, **_get_xr_cftime_kwargs()) as precipds:

The helper always returns use_cftime=True, which forces xarray to decode the time coordinate as cftime datetime objects (dtype object) instead of numpy.datetime64. This causes issues downstream when the input file uses a standard Gregorian calendar, where numpy datetime decoding works correctly and is expected.

Steps to reproduce:

import xarray as xr
from oggm import cfg, workflow, tasks

cfg.initialize(logging_level='ERROR')
cfg.PARAMS['baseline_climate'] = 'ERA5'
cfg.PATHS['working_dir'] = '/tmp/oggm_test/'

gdirs = workflow.init_glacier_directories(["RGI60-14.14599"], from_prepro_level=2)
workflow.execute_entity_task(tasks.process_climate_data, gdirs)

# File with standard calendar
workflow.execute_entity_task(tasks.process_cmip_data, gdirs,
                             fpath_temp="my_standard_calendar.nc",
                             fpath_precip="my_standard_calendar.nc")

Loading the same file directly gives datetime64[ns]:

ds = xr.open_dataset("my_standard_calendar.nc")
print(ds.time.dtype)  # datetime64[ns]

But via process_cmip_data the time coordinate has dtype object (cftime).

Expected behavior:

For files with a standard calendar, the time coordinate should be decoded as datetime64[ns]. The cftime fallback is only needed for non-standard calendars (e.g. 360_day, noleap).

Suggested fix:

Add a use_cftime=False default to _get_xr_cftime_kwargs so standard calendar files use numpy decoding by default, while non-standard calendar files can still opt in:

def _get_xr_cftime_kwargs(use_cftime=False):
    if not use_cftime:
        return {}
    try:
        return {'decode_times': xr.coders.CFDatetimeCoder(use_cftime=True)}
    except AttributeError:
        return {'use_cftime': True}

Environment:

• xarray: 2026.4.0
• oggm: 1.6.4.dev1+g76f44230b
• cftime: 1.6.5
• netCDF4: 1.7.4

[fmaussion]

Thanks for the report! I'm not entirely opposed to this, but using cftime=True everywhere has the benefit of being consistent with little downsides I am aware of. In general I found it easier to have no if cases if possible and simply build a workflow assuming cftime regardless of the calendar (OGGM internally is completely calendar-ignorant, until daily data came in).

Can you specify what kind of issues does cftime create for your workflow?

@pat-schmitt - is dev affected by this as well, i.e. you are converting back to datetime?

[rodaguayo]

Thanks Fabien! We mainly ran into this when using custom GCM/RCM inputs with standard Gregorian calendars. With newer xarray versions, forcing use_cftime=True turns time coordinates that would normally be datetime64[ns] into objects, which then causes some downstream compatibility issues.

So the problem is not really the calendar handling itself, but that OGGM overrides xarray’s default decoding even for standard calendars that already work fine natively.