Offset of “time” dim for terra packages when reading nc file

[Breeze-Hu]

When I open an nc file using terra, the time dimension of the read data is off by 3 days. The description of the data source should read: 1961-01-01 to 2022-12-31. But the result read using terra is: 1961-01-03 to 2023-01-02 UTC.
The same file was read using xarray in python. The time dimension of the data is normal.

In seeking a solution to the problem, I may have seen a similar situation with other people's data (I'm not sure): [R terra not reading attributes from NetCDF file](https://gis.stackexchange.com/questions/435439/r-terra-not-reading-attributes-from-netcdf-file?newreg=53533f541898458f823f125d42773ca8).Though this is monthly data, so it doesn't have an impact on what's in the study.

But, this issue would be very problematic for daily data.

operating system：

macOS：14.6.1

packageVersion("terra")
[1] ‘1.7.78’

terra::gdal(lib="all")
gdal proj geos
"3.5.3" "9.1.0" "3.11.0"

[Breeze-Hu]

I tried to find the cause of this problem in other ways. I checked ‘Panoply’ Panoply netCDF, HDF and GRIB Data Viewer read of this file and the result is consistent with xarray (1961-01-01).

But when using the python base package 'datetime' to do the calculations, the results are consistent with terra.
I looked at the documentation for xarray, and it points to the use of CF conventions rules in the date calculation process.

When reading or writing netCDF files, xarray automatically decodes datetime and timedelta arrays using CF conventions
cf-conventions

Perhaps this discrepancy is the result.

[rhijmans]

Can your provide an example file?

[Breeze-Hu]

Hello developer!
I've now uploaded a sample datasetexample.nc and to reduce the size of the dataset, I've cut the original dataset of the question in time.
And I checked to be able to reproduce the question.

The reason for the problem was given a very detailed response by the author of another package pvanlaake/CFtime#9.

This proves that it's not a problem with the terra package (maybe this isn't really a bug, but rather a habit of creating datas)

[Breeze-Hu]

This issue in CFtime package may be resolved in the near future.
pvanlaake/CFtime#9 (comment)