Rust-based cftime Implementation for Python

[antscloud]

Is your feature request related to a problem?

I developped a rust based project with python bindings code to parse the CF time conventions and deal with datetime operations.

You can find the project on GitHub at https://github.com/antscloud/cftime-rs.

It was something missing in the rust ecosystem to deal with NetCDF files, As the project in Rust hits its first working version, I wanted to explore the maturin ecosystem and the Rust as a backend for python code.
I ended up creating a new cftime implementation for python that have significant perfomance improvement (somewhere between 4 times to 20 times faster depending on the use case) over cftime original Cython code.

There are surely missing features compared to cftime and need to be tested more, but I think it could be interested as a replacement for some xarray operations (mainly for speed) regarding some of the issues of topic-cftime label

Please, let me know if xarray team could be interested. If you are, I can open a pull request to see it is possible, where it breaks the unit tests and if it's worth it

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

[dcherian]

Please, let me know if xarray team could be interested. If you are, I can open a pull request to see it is possible, where it breaks the unit tests and if it's worth it

Absolutely!

Ideally we'd work on #155 some but for now I'd starting hacking here:

xarray/xarray/coding/times.py

Line 803 in 338fc92

class CFDatetimeCoder(VariableCoder):

[spencerkclark]

Thanks for sharing @antscloud! This seems like a cool library, and looks fairly cleanly written from first glance. I have some questions about some design decisions, but we can save those until later.

Would you be willing to open an issue within the cftime repository itself? Before discussing wholesale switching from one datetime type to another in xarray, which would be disruptive to xarray and downstream users, I'm wondering if changes could instead be discussed/made upstream? An initial question I am curious about is: to what extent are the performance limitations of cftime language-based vs. algorithm-based? This is a backend-related question, which, regardless of the answer, would in principle allow for maintaining the same frontend API (and thus require no changes in xarray).

Finally, one other question which would be relevant before moving forward with anything in cftime or xarray is: how tied are you to the AGPL license? Would you be open to switching to a more permissive license instead of a copyleft license? The reason for asking is that copyleft licenses restrict the types of licenses that can be used in work that depends on your project (see for example discussion here).