CDO

What do you mean exactly?

original:
int time(time) ;
time:long_name = "time" ;
time:units = "minutes since 2006-07-01 01:30:00" ;
time:time_increment = 30000 ;
time:begin_date = 20060701 ;
time:begin_time = 13000 ;
time:vmax = 1.e+15f ;
time:vmin = -1.e+15f ;
time:valid_range = -1.e+15f, 1.e+15f ;

cdo output:
double time(time) ;
time:standard_name = "time" ;
time:long_name = "time" ;
time:units = "minutes since 2006-07-01 01:30:00" ;
time:calendar = "standard" ;
time:axis = "T" ;

Applied to all 3D MERRA2 datasets. A sample file was attached
https://code.mpimet.mpg.de/boards/2/topics/7521?r=7545#message-7545

Nope, in my opinion the CF-convention says that the time dimension has to be of type double and CDO follows the CF-convention.

I understand double time would be recommended but CF-convention does not say it has to be double.

I cannot find a clear definition of the data type here, CF says more about units. It's clear, that information is lost as soon as you do shifts, computations or unit changes on integer-based time-coordinates. That's the reason why CDO does a conversion right away.

you can convert back to int with

ncap2 -s 'time=int(time)' <input> <output>

hth
ralf

Thank you Ralf,

I fully appreciate the benefits of a double time, but not all the datasets will undergo shifts, computations or unit changes, therefore it does not have to be double.

We are serving users online and additional conversion will cause unnecessary I/O load, not tiny when the number of jobs is huge.

It would be best to provide an option for us to not convert time data type, and in general, not to change any attributes if possible.

Thanks,
Jay

Second this.

The integer datatype for the time will not be changed in the next CDO release 1.9.8 anymore!

Cheers,
Uwe