Bug with reinterpret

[ph-kev]

Describe the bug

I cannot reinterpret a DateTimeNoLeap to a DateTimeStandard from a NetCDF file. I was also not sure if this bug belongs in NCDatasets.jl or here.

To Reproduce

I will try to find a simpler reproducer that doesn't use ClimaLand but this reproduces the bug I am facing.

import ClimaLand
import CFTime
import NCDatasets

filepath = ClimaLand.Artifacts.cesm2_albedo_dataset_path()
ds = NCDatasets.NCDataset(filepath)

# This line fails
# Note that ds["time"][4] == CFTime.DateTimeNoLeap(1850, 4, 15) but not ===
reinterpret(CFTime.DateTimeStandard, ds["time"][4])

Here is a dump of ds["time"][4]:

julia> ds["time"][4] |> dump
CFTime.DateTimeNoLeap{CFTime.Period{Float64, Val{86400}(), Val{0}()}, Val{(1, 1, 1)}()}
  instant: CFTime.Period{Float64, Val{86400}(), Val{0}()}
    duration: Float64 674989.0

The versions I am using are:

(jl_zS88Fm) pkg> st
Status `/tmp/jl_zS88Fm/Project.toml`
  [179af706] CFTime v0.2.7
  [08f4d4ce] ClimaLand v1.6.3
  [85f8d34a] NCDatasets v0.14.13

Expected behavior

I would expect reinterpret(CFTime.DateTimeStandard, CFTime.DateTimeNoLeap(1850, 4, 15)) to return DateTimeStandard(1850-04-15T00:00:00).

Environment

I am using

• operating system: Ubuntu 24.04.4
• Julia version: 1.12.5

Full output

ERROR: LoadError: MethodError: no method matching CFTime.DateTimeStandard(::Int64, ::Int64, ::Int64, ::Float64, ::Float64, ::Float64, ::Float64)
The type `CFTime.DateTimeStandard` exists, but no method is defined for this combination of argument types when trying to construct it.

Closest candidates are:
  CFTime.DateTimeStandard(::DataType, ::Any...; origin, units)
   @ CFTime ~/.julia/packages/CFTime/EgIxc/src/datetime.jl:125
  CFTime.DateTimeStandard(::Integer, ::Integer...; kwargs...) where N
   @ CFTime ~/.julia/packages/CFTime/EgIxc/src/datetime.jl:155
  CFTime.DateTimeStandard(::T, ::AbstractString) where T<:Number
   @ CFTime ~/.julia/packages/CFTime/EgIxc/src/datetime.jl:146
  ...

Stacktrace:
 [1] reinterpret @ CFTime ~/.julia/packages/CFTime/EgIxc/src/conversions.jl:103
...

[Alexander-Barth]

Thank you for reporting this issue. This should be fixed now.