Timezones a-la chrono-tz

[jorgecarleitao]

Fixed offsets do not take summer times and others into account. Is there a sibling crate with definitions of other timezones?

We use chrono in arrow2 but I am a bit wary of it being unmaintained. However, we currently depend on chrono and chrono-tz for more useful timezones.

Operations where we use chrono and chrono-tz:

/// Adds an `interval` to a `timestamp` in `time_unit` units without timezone.
pub fn add_naive_interval(timestamp: i64, time_unit: TimeUnit, interval: months_days_ns) -> i64;

/// Adds an `interval` to a `timestamp` in `time_unit` units and timezone `timezone`.
pub fn add_interval<T: chrono::TimeZone>(
    timestamp: i64,
    time_unit: TimeUnit,
    interval: months_days_ns, // [i32, i32, i64]
    timezone: &T,
) -> i64

/// Time units defined in Arrow.
#[derive(Debug, Clone, Copy, PartialEq, Eq, Hash)]
pub enum TimeUnit {
    /// Time in seconds.
    Second,
    /// Time in milliseconds.
    Millisecond,
    /// Time in microseconds.
    Microsecond,
    /// Time in nanoseconds.
    Nanosecond,
}

/// The in-memory representation of the MonthDayNano variant of the "Interval" logical type.
pub struct months_days_ns(i32, i32, i64);

Adding days and ns to a datetime with a timezone requires these non-trivial time-shifts.

[jhpratt]

Looks like you're asking for two separate things here: tzdb integration and a Period type. Both are planned.

tzdb support (tracked by #193) is what will provide time zones rather than just fixed offsets. This will let you subtract two dates over a DST shift and get the appropriate Duration (such as 23 or 25 hours rather than 24).

A Period type is what will allow you to take January 1 and add one month, rather than requiring a number of days (which of course varies by month). It would be able to be added to and subtracted from all of the types you'd expect. That will include ZonedDateTime or whatever it ends up being called.

[jhpratt]

Sure, but at that point you already have the end. May as well just calculate it directly, which is what a Period type would do.

In the future you will be able to do something like

datetime!(2021-01-01 0:00 America/New_York) + Period { months: 2, days: 6, seconds: 18, ..Period::ZERO }

and get 2021-03-07 0:00:18 in US eastern time. If performed on the same date in 2020, you'd get the same result (obviously in 2020). It looks like that is what you're looking for from the TimeUnit enum, no?

[jorgecarleitao]

The end is adding months_days_ns to a zonedDateTime just like you wrote. I was just pointing out that the tzdb is necessary to work with periods, while periods without tzdb only work up to days for zoned datetimes.

I think we are in agreement here :)

[jhpratt]

Nah, you could definitely do datetime!(2021-01-01 0:00 -5:00) + Period { months: 2, days: 6, seconds: 18, ..Period::ZERO }. For reasons that you appear to understand, that wouldn't change the UTC offset if it crosses a DST boundary. But it is possible to implement on things other than a ZonedDateTime which wouldn't require tzdb.

[jorgecarleitao]

ahh, I see, you are right, they are independent indeed. Thanks for the clarification.

[jhpratt]

Once I (eventually) get around to cleaning up docs and writing at least part of the book for time 0.3, a Period type is next in priority.