Perhaps this is out-of-scope, but I'm wondering if you have a plan to support the TZ (and maybe TZDIR) environment variables so that we can reproduce behavior of, for example,

$ TZ="FOO+12:34" date "+%Z %z"
FOO -1234
$ TZ=":Cuba" date "+%Z %z"
CST -0500

This provides an implementation of the TZ POSIX environment variable specification for timezone information.

This exposes a new API function time_tz::parse_tz::parse(input: &str) which returns an owned type implementing the TimeZone trait.

This currently needs a lot of testing to ensure the hacks works and the many "unwrap" also passes.

Link to the spec: https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08_03

When using assume_timezone on a PrimitiveDateTime close to the forward DST changeover, I get an unexpected result for the offset in the end. In my opinion, time-tz does not yet handle the timezone correctly in this situation.

The following test demonstrates the issue. I've also included a test for the backward changeover, but I think the behaviour there is acceptable.

mod time_tz {
    use time::macros::datetime;
    use time_tz::timezones::db::CET;
    use time_tz::PrimitiveDateTimeExt as _;

    #[test]
    fn handles_forward_changeover() {
        assert_eq!(
            datetime!(2022-03-27 01:30).assume_timezone(CET),
            datetime!(2022-03-27 01:30 +01:00)
        );
    }

    #[test]
    fn handles_backward_changeover() {
        // During backward changeover, the hour between 02:00 and 03:00 occurs twice, so either answer is correct
        /* assert_eq!(
            datetime!(2022-10-30 02:30).assume_timezone(CET),
            datetime!(2022-10-30 02:30 +02:00)
        ); */
        assert_eq!(
            datetime!(2022-10-30 02:30).assume_timezone(CET),
            datetime!(2022-10-30 02:30 +01:00)
        );
    }
}

On 2022-03-27, the date of DST changeover in CET, 01:30 in CET is 00:30 in UTC, but 01:30 in UTC is 03:30 in CET due to DST changeover.

My expectation of assume_timezone was that it behaves similar to assume_offset on PrimitiveDateTime, which considers the PrimitiveDateTime to be in the provided offset.

The exhibited behaviour is correct when treating the PrimitiveDateTime as UTC, but I'd argue that this would not be very useful. If this is indeed the expected behaviour, the documentation should highlight this fact.

I think the issue comes down to this line in assume_timezone:

let offset = tz.get_offset_utc(&self.assume_utc());

For completeness, I've included the behaviour of chrono-tz. Note that the second test panics, since the local time 02:30 is ambiguous during backward DST changeover in CET.

mod chrono {
    use chrono::NaiveDate;
    use chrono::NaiveDateTime;
    use chrono::NaiveTime;
    use chrono::TimeZone;
    use chrono_tz::CET;

    #[test]
    fn handles_forward_changeover() {
        let local = CET
            .from_local_datetime(&NaiveDateTime::new(
                NaiveDate::from_ymd(2022, 3, 27),
                NaiveTime::from_hms(01, 30, 00),
            ))
            .unwrap();

        assert_eq!(local, CET.ymd(2022, 3, 27).and_hms(01, 30, 00));
    }

    #[test]
    #[should_panic]
    fn handles_backward_changeover() {
        let local = CET
            .from_local_datetime(&NaiveDateTime::new(
                NaiveDate::from_ymd(2022, 10, 30),
                NaiveTime::from_hms(02, 30, 00),
            ))
            .unwrap();

        assert_eq!(local, CET.ymd(2022, 10, 30).and_hms(02, 30, 00));
        assert_eq!(local, CET.ymd(2022, 10, 30).and_hms(02, 30, 00));
    }
}

This PR finally fixes the behavior of assume_timezone and assume_timezone_utc. The assume_timezone function is now fixed to always assume the input PrimitiveDateTime is already in the target timezone. The assume_timezone_utc preserves the old behavior of assuming the input PrimitiveDateTime is actually in UTC.

Fixes #5 Fixes #6

DST values are not included in the values output by OffsetDateTimeExt::to_timezone and PrimitiveDateTimeExt::to_timezone. For example the code below:

use time::macros::datetime; use time_tz::{timezones, TimeZone, OffsetDateTimeExt}; let london = timezones::db::europe::LONDON; let odt1 = datetime!(2021-01-01 12:0:0 UTC); println!("{:?}", london.get_offset_utc(&odt1)); println!("{}", odt1.to_timezone(london)); let odt2 = datetime!(2021-07-01 12:0:0 UTC); println!("{:?}", london.get_offset_utc(&odt2)); println!("{}", odt2.to_timezone(london));

gives the following output:

TzOffset { timespan: FixedTimespan { utc_offset: 0, dst_offset: 0, name: "GMT" } } 2021-01-01 12:00:00.0 +00:00:00 TzOffset { timespan: FixedTimespan { utc_offset: 0, dst_offset: 3600, name: "BST" } } 2021-07-01 12:00:00.0 +00:00:00

Note that to_timezone gives an offset of zero for both dates even though the TzOffset instances are clearly different. The final line should have an offset of +1 hour.

The source of the problem lies in the impl of Offset::to_utc for TzOffset in timezone_impl.rs. I believe the line:

UtcOffset::from_whole_seconds(self.timespan.utc_offset as i32).unwrap()

should read:

UtcOffset::from_whole_seconds((self.timespan.utc_offset + self.timespan.dst_offset) as i32).unwrap()

get_timezone() always returns Error::Undetermined unless summer time is used in the current locale.

According to Documentation:

Return value

If the function succeeds, it returns one of the following values. | Return code/value | Description | |-|-| | TIME_ZONE_ID_UNKNOWN 0 | Daylight saving time is not used in the current time zone, because there are no transition dates. |

Code 0 means success so you have to return the fetched timezone instead of Error::Undetermined.

Thank you for the amazing crate! This PR consists of two commits: The first commit of the change implements std::error::Error for Error type so that it's easier for users to propagate the error returned by time-tz. The second commit is a result of cargo fmt, as I noticed there are some formatting issues like mixed tab-indentations and spaces-indentations.

Currently the behavior of assume_timezone is ambiguous: one might expect the given PrimitiveDateTime to be in UTC, another could expect the function to directly accept a PrimitiveDateTime which is in the destination timezone.

I think the way forward is to deprecate the function assume_timezone as soon as possible, forwarding users to the replacement assume_timezone_utc which assumes the PrimitiveDateTime is already in UTC. Also necessary is to provide a clear documentation on how this new replacement actually works and make it clear it takes UTC!

Currently the function assume_timezone is not intended to be used with non UTC PrimitiveDateTime and produces wrong values when close to DST changeover.

We need a new API function to handle creating an OffsetDateTime from a PrimitiveDateTime and a Timezone assuming the given PrimitiveDateTime is already in the proper timezone.

I think of introducing a new version of the library to handle the changeover in the current function named assume_timezone and introducing a new function named assume_timezone_utc to keep the current behavior of assuming the given PrimitiveDateTime is in UTC.

Unresolved questions:

• What's the best way to handle this?

Additional doc:

Testing code (thanks korrat) - to integrate as UT once implementation is done:

mod time_tz {
    use time::macros::datetime;
    use time_tz::timezones::db::CET;
    use time_tz::PrimitiveDateTimeExt as _;

    #[test]
    fn handles_forward_changeover() {
        assert_eq!(
            datetime!(2022-03-27 01:30).assume_timezone(CET),
            datetime!(2022-03-27 01:30 +01:00)
        );
    }

    #[test]
    fn handles_backward_changeover() {
        // During backward changeover, the hour between 02:00 and 03:00 occurs twice, so either answer is correct
        /* assert_eq!(
            datetime!(2022-10-30 02:30).assume_timezone(CET),
            datetime!(2022-10-30 02:30 +02:00)
        ); */
        assert_eq!(
            datetime!(2022-10-30 02:30).assume_timezone(CET),
            datetime!(2022-10-30 02:30 +01:00)
        );
    }
}

Sorry for the not so short text below, but I thought some context was needed before exposing what I'd like to do.

Context

In the beginning of the year 2022, reacting to CVE-2020-26235, I migrated some of the repositories I was working on, from chrono to time, until I stumbled on some functionalities that needed to parse timezones. Then, I opened https://github.com/chronotope/chrono-tz/pull/93.

That said, the PR I proposed is not really satisfying:

1. with the name chrono_tz, you would expect to have chrono in it (so making chrono an optional feature sounds dumb)
2. it looks like the extract from the IANA Database is a functionality by itself that might live in its own repository

It's the second item that made me opened this issue (see below).

What I'd like to do?

I only found out today about your crate time-tz. I'm pretty happy about it because I'm pretty sure I'm gonna use it:smile:

I quickly parsed the code from build.rs and it seems mostly similar to chrono-tz-build. I was actually already trying to extract that part into an independent crate (when working on https://github.com/chronotope/chrono-tz/pull/93). Would you be interested in such a modification? I'd be interested to actually do the work but I'd like to know first if the idea is sound and acceptable in your project?