Feature request: support for daylight savings time

[kybishop]

I went investigating DST support in chrono after needing it for an app. I stumbled on this issue, but it looks like DST support is still a ways off. I was hoping to bring the status of DST support into a single issue for better tracking, and to see if there is anything I/the community could do to help out.

Thanks!

[djzin]

Does chrono-tz solve your problem?

[kybishop]

@djzin yes! Thanks a bunch for the lib!

[vertexua]

I am not pro in dates and time, but it feel inconsistent. This code works

extern crate chrono;
extern crate chrono_tz;
extern crate time;

use chrono::prelude::*;
use chrono_tz::Europe::Berlin;

fn main() {
    let mut d = Berlin.ymd(2018, 10, 28).and_hms(1, 30, 0);
    for _ in 0 .. 10 {
        println!("{:?}", d);
        d = d + time::Duration::minutes(30);
    }
}

But let me change this to "and_hms(2, 30, 0)" and chrono_tz explicitly panics as it is invalid date. At the same time gradually adding 30 minutes works fine and prints a non-interrupted sequence of time with "CEST" as a timezone. Can you comment pls? One library allows creation of certain time, another explicitly prohibits. Is this expected?

[vertexua]

Am I understanding this right, that it is a matter of printing, but while we switch from CEST to CET, it is still possible to print the time in CEST, if it was hypothetically the current timezone. And this is what the framework does, because the "+" operation does not want to mutate the timezone. The selection of the sub-timezone (or whatever is the term) is only happening at creation time, but not refreshed at "+". It is up to the user to trigger the refresh of the sub-timezone (is there an API? For example that does not require to specify CET explicitly, but will somehow derive it from Berlin again for a new time)

This has it's own sense and certainly helps performance, but this is incredibly unexpected. I can imagine times appearing at the weird timezones just because they came from from an obscure formula and had a different initial sub-timezone at the be beginning.

[pitdicker]

Sorry for the late reply, I am going through old issues...

I am not pro in dates and time, but it feel inconsistent. This code works

extern crate chrono;
extern crate chrono_tz;
extern crate time;

use chrono::prelude::*;
use chrono_tz::Europe::Berlin;

fn main() {
    let mut d = Berlin.ymd(2018, 10, 28).and_hms(1, 30, 0);
    for _ in 0 .. 10 {
        println!("{:?}", d);
        d = d + time::Duration::minutes(30);
    }
}

But let me change this to "and_hms(2, 30, 0)" and chrono_tz explicitly panics as it is invalid date. At the same time gradually adding 30 minutes works fine and prints a non-interrupted sequence of time with "CEST" as a timezone. Can you comment pls? One library allows creation of certain time, another explicitly prohibits. Is this expected?

Good example. In more recent versions of chrono you would write this as:

use chrono::{Duration, TimeZone};
use chrono_tz::Europe::Berlin;

fn main() {
    let mut d = Berlin.with_ymd_and_hms(2018, 10, 28, 1, 30, 0).unwrap(); // This returns a `LocalResult`
    for _ in 0 .. 10 {
        println!("{:?}", d);
        d = d + Duration::minutes(30);
    }
}

Notice the place where a LocalResult is returned. If you change the time to 2:30 it will return LocalResult::Ambiguous, and unwrapping gives the panic:

thread 'main' panicked at 'Ambiguous local time, ranging from 2018-10-28T02:30:00CEST to 2018-10-28T02:30:00CET', src/main.rs:5:65
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

You can use the methods earliest() and latest() to pick which one to use.