cftime-rs
cftime-rs
is an implementation in rust
of the cf time convention. Python bindins are available for this project and use the great maturin library. The python bindings are highly inspired by the cftime python package developped by Unidata.
Rust
Installation
cargo install cftime-rs
Examples
Decoding
Decoding needs units, and calendar and can work with i32
, i64
, f32
, f64
and their corresponding vector type Vec<i32>
, Vec<i64>
, Vec<f32>
and Vec<f64>
. From these type it return either a CFDatetime
object or a Vec<CFDatetime>
.
use Calendar;
use *;
use FromStr;
will print :
2000-01-01 00:00:00.000
2000-01-02 00:00:00.000
2000-01-03 00:00:00.000
2000-01-04 00:00:00.000
2000-01-05 00:00:00.000
2000-01-06 00:00:00.000
Encoding
Encoding needs units and calendar and can convert a CFDatetime
object into an i32
, i64
, f32
or f64
or a Vec<CFDatetime>
into Vec<i32>
, Vec<i64>
, Vec<f32>
or Vec<f64>
.
use Calendar;
use CFDatetime;
use *;
use Error;
use FromStr;
will print :
0
1
2
3
4
5
Python
Installation
pip install cftime-rs
Examples
Decoding to PyCfDatetimes
=
=
=
=
will print :
2000-01-01 00:00:00.000
2000-01-02 00:00:00.000
2000-01-03 00:00:00.000
2000-01-04 00:00:00.000
2000-01-05 00:00:00.000
2000-01-06 00:00:00.000
Encoding PyCFDatetimes
=
=
=
=
=
will print :
0
1
2
3
4
5
Decoding to Python datetimes
=
=
=
=
will print
2000-01-01 00:00:00
2000-01-02 00:00:00
2000-01-03 00:00:00
2000-01-04 00:00:00
2000-01-05 00:00:00
2000-01-06 00:00:00
Decoding Python datetimes
=
=
=
=
will print
0
1
2
3
4
5
Known issues
While this date calculation library can handle a wide range of dates, from approximately -291,672,107,014 BC to 291,672,107,014 AD, there are some performance considerations you should be aware of. As you move further away from the reference date of 1970-01-01 00:00:00, the time of calculation increases. This is because the library needs to account for leap years in various calendars.
Here is an example of the computation of 1_000_000_000_000_000 seconds using the units "seconds since 2000-01-01 00:00:00" on my personal computer in release mode :
Calendar | Computation Time |
---|---|
Standard Calendar | 44.470405ms |
Leap Day Calendar | 8.052179ms |
360-Day Calendar | 12.834µs |
Comparison with cftime
Here is a benchmark on my computer of three methods. This is not really rigorous but this is to give an idea.
We are comparing cftime with cftime_rs. The first method involves decoding a series of numbers using the standard calendar, calling the .str() method, and then re-encoding them to the same unit and calendar. The second method is to decode a series of numbers using the standard calendar and re-encode them to the same unit and calendar without calling .str(). The third method is to decode a series of numbers using the standard calendar into python datetimes and re-encode them to the same unit and calendar without calling .str().
First and second methods are designed to be fair between the two libraries because cftime_rs only uses timestamps (i64) as its internal representation and never recalculates the year, month, day, hour, minutes, and seconds, except if you explicitly request this representation.