Date and time library for Rust

Last update: May 25, 2022

Chrono: Date and Time for Rust

Chrono GitHub Actions Chrono on crates.io Chrono on docs.rs Join the chat at https://gitter.im/chrono-rs/chrono

It aims to be a feature-complete superset of the time library. In particular,

  • Chrono strictly adheres to ISO 8601.
  • Chrono is timezone-aware by default, with separate timezone-naive types.
  • Chrono is space-optimal and (while not being the primary goal) reasonably efficient.

There were several previous attempts to bring a good date and time library to Rust, which Chrono builds upon and should acknowledge:

Any significant changes to Chrono are documented in the CHANGELOG.md file.

Usage

Put this in your Cargo.toml:

[dependencies]
chrono = "0.4"

Features

Chrono supports various runtime environments and operating systems, and has several features that may be enabled or disabled.

Default features:

  • alloc: Enable features that depend on allocation (primarily string formatting)
  • std: Enables functionality that depends on the standard library. This is a superset of alloc and adds interoperation with standard library types and traits.
  • clock: enables reading the system time (now), independent of whether std::time::SystemTime is present, depends on having a libc.

Optional features:

  • wasmbind: Enable integration with wasm-bindgen and its js-sys project
  • serde: Enable serialization/deserialization via serde.
  • unstable-locales: Enable localization. This adds various methods with a _localized suffix. The implementation and API may change or even be removed in a patch release. Feedback welcome.

See the cargo docs for examples of specifying features.

Overview

Duration

Chrono currently uses its own [Duration] type to represent the magnitude of a time span. Since this has the same name as the newer, standard type for duration, the reference will refer this type as OldDuration.

Note that this is an "accurate" duration represented as seconds and nanoseconds and does not represent "nominal" components such as days or months.

When the oldtime feature is enabled, [Duration] is an alias for the time::Duration type from v0.1 of the time crate. time v0.1 is deprecated, so new code should disable the oldtime feature and use the chrono::Duration type instead. The oldtime feature is enabled by default for backwards compatibility, but future versions of Chrono are likely to remove the feature entirely.

Chrono does not yet natively support the standard Duration type, but it will be supported in the future. Meanwhile you can convert between two types with Duration::from_std and Duration::to_std methods.

Date and Time

Chrono provides a DateTime type to represent a date and a time in a timezone.

For more abstract moment-in-time tracking such as internal timekeeping that is unconcerned with timezones, consider time::SystemTime, which tracks your system clock, or time::Instant, which is an opaque but monotonically-increasing representation of a moment in time.

DateTime is timezone-aware and must be constructed from the TimeZone object, which defines how the local date is converted to and back from the UTC date. There are three well-known TimeZone implementations:

  • Utc specifies the UTC time zone. It is most efficient.

  • Local specifies the system local time zone.

  • FixedOffset specifies an arbitrary, fixed time zone such as UTC+09:00 or UTC-10:30. This often results from the parsed textual date and time. Since it stores the most information and does not depend on the system environment, you would want to normalize other TimeZones into this type.

DateTimes with different TimeZone types are distinct and do not mix, but can be converted to each other using the DateTime::with_timezone method.

You can get the current date and time in the UTC time zone (Utc::now()) or in the local time zone (Local::now()).

use chrono::prelude::*;

let utc: DateTime<Utc> = Utc::now();       // e.g. `2014-11-28T12:45:59.324310806Z`
let local: DateTime<Local> = Local::now(); // e.g. `2014-11-28T21:45:59.324310806+09:00`

Alternatively, you can create your own date and time. This is a bit verbose due to Rust's lack of function and method overloading, but in turn we get a rich combination of initialization methods.

use chrono::prelude::*;
use chrono::offset::LocalResult;

let dt = Utc.ymd(2014, 7, 8).and_hms(9, 10, 11); // `2014-07-08T09:10:11Z`
// July 8 is 188th day of the year 2014 (`o` for "ordinal")
assert_eq!(dt, Utc.yo(2014, 189).and_hms(9, 10, 11));
// July 8 is Tuesday in ISO week 28 of the year 2014.
assert_eq!(dt, Utc.isoywd(2014, 28, Weekday::Tue).and_hms(9, 10, 11));

let dt = Utc.ymd(2014, 7, 8).and_hms_milli(9, 10, 11, 12); // `2014-07-08T09:10:11.012Z`
assert_eq!(dt, Utc.ymd(2014, 7, 8).and_hms_micro(9, 10, 11, 12_000));
assert_eq!(dt, Utc.ymd(2014, 7, 8).and_hms_nano(9, 10, 11, 12_000_000));

// dynamic verification
assert_eq!(Utc.ymd_opt(2014, 7, 8).and_hms_opt(21, 15, 33),
           LocalResult::Single(Utc.ymd(2014, 7, 8).and_hms(21, 15, 33)));
assert_eq!(Utc.ymd_opt(2014, 7, 8).and_hms_opt(80, 15, 33), LocalResult::None);
assert_eq!(Utc.ymd_opt(2014, 7, 38).and_hms_opt(21, 15, 33), LocalResult::None);

// other time zone objects can be used to construct a local datetime.
// obviously, `local_dt` is normally different from `dt`, but `fixed_dt` should be identical.
let local_dt = Local.ymd(2014, 7, 8).and_hms_milli(9, 10, 11, 12);
let fixed_dt = FixedOffset::east(9 * 3600).ymd(2014, 7, 8).and_hms_milli(18, 10, 11, 12);
assert_eq!(dt, fixed_dt);

Various properties are available to the date and time, and can be altered individually. Most of them are defined in the traits Datelike and Timelike which you should use before. Addition and subtraction is also supported. The following illustrates most supported operations to the date and time:

use chrono::prelude::*;
use chrono::Duration;

// assume this returned `2014-11-28T21:45:59.324310806+09:00`:
let dt = FixedOffset::east(9*3600).ymd(2014, 11, 28).and_hms_nano(21, 45, 59, 324310806);

// property accessors
assert_eq!((dt.year(), dt.month(), dt.day()), (2014, 11, 28));
assert_eq!((dt.month0(), dt.day0()), (10, 27)); // for unfortunate souls
assert_eq!((dt.hour(), dt.minute(), dt.second()), (21, 45, 59));
assert_eq!(dt.weekday(), Weekday::Fri);
assert_eq!(dt.weekday().number_from_monday(), 5); // Mon=1, ..., Sun=7
assert_eq!(dt.ordinal(), 332); // the day of year
assert_eq!(dt.num_days_from_ce(), 735565); // the number of days from and including Jan 1, 1

// time zone accessor and manipulation
assert_eq!(dt.offset().fix().local_minus_utc(), 9 * 3600);
assert_eq!(dt.timezone(), FixedOffset::east(9 * 3600));
assert_eq!(dt.with_timezone(&Utc), Utc.ymd(2014, 11, 28).and_hms_nano(12, 45, 59, 324310806));

// a sample of property manipulations (validates dynamically)
assert_eq!(dt.with_day(29).unwrap().weekday(), Weekday::Sat); // 2014-11-29 is Saturday
assert_eq!(dt.with_day(32), None);
assert_eq!(dt.with_year(-300).unwrap().num_days_from_ce(), -109606); // November 29, 301 BCE

// arithmetic operations
let dt1 = Utc.ymd(2014, 11, 14).and_hms(8, 9, 10);
let dt2 = Utc.ymd(2014, 11, 14).and_hms(10, 9, 8);
assert_eq!(dt1.signed_duration_since(dt2), Duration::seconds(-2 * 3600 + 2));
assert_eq!(dt2.signed_duration_since(dt1), Duration::seconds(2 * 3600 - 2));
assert_eq!(Utc.ymd(1970, 1, 1).and_hms(0, 0, 0) + Duration::seconds(1_000_000_000),
           Utc.ymd(2001, 9, 9).and_hms(1, 46, 40));
assert_eq!(Utc.ymd(1970, 1, 1).and_hms(0, 0, 0) - Duration::seconds(1_000_000_000),
           Utc.ymd(1938, 4, 24).and_hms(22, 13, 20));

Formatting and Parsing

Formatting is done via the format method, which format is equivalent to the familiar strftime format.

See format::strftime documentation for full syntax and list of specifiers.

The default to_string method and {:?} specifier also give a reasonable representation. Chrono also provides to_rfc2822 and to_rfc3339 methods for well-known formats.

Chrono now also provides date formatting in almost any language without the help of an additional C library. This functionality is under the feature unstable-locales:

chrono = { version = "0.4", features = ["unstable-locales"] }

The unstable-locales feature requires and implies at least the alloc feature.

use chrono::prelude::*;

let dt = Utc.ymd(2014, 11, 28).and_hms(12, 0, 9);
assert_eq!(dt.format("%Y-%m-%d %H:%M:%S").to_string(), "2014-11-28 12:00:09");
assert_eq!(dt.format("%a %b %e %T %Y").to_string(), "Fri Nov 28 12:00:09 2014");
assert_eq!(dt.format_localized("%A %e %B %Y, %T", Locale::fr_BE).to_string(), "vendredi 28 novembre 2014, 12:00:09");

assert_eq!(dt.format("%a %b %e %T %Y").to_string(), dt.format("%c").to_string());
assert_eq!(dt.to_string(), "2014-11-28 12:00:09 UTC");
assert_eq!(dt.to_rfc2822(), "Fri, 28 Nov 2014 12:00:09 +0000");
assert_eq!(dt.to_rfc3339(), "2014-11-28T12:00:09+00:00");
assert_eq!(format!("{:?}", dt), "2014-11-28T12:00:09Z");

// Note that milli/nanoseconds are only printed if they are non-zero
let dt_nano = Utc.ymd(2014, 11, 28).and_hms_nano(12, 0, 9, 1);
assert_eq!(format!("{:?}", dt_nano), "2014-11-28T12:00:09.000000001Z");

Parsing can be done with three methods:

  1. The standard FromStr trait (and parse method on a string) can be used for parsing DateTime<FixedOffset>, DateTime<Utc> and DateTime<Local> values. This parses what the {:?} (std::fmt::Debug) format specifier prints, and requires the offset to be present.

  2. DateTime::parse_from_str parses a date and time with offsets and returns DateTime<FixedOffset>. This should be used when the offset is a part of input and the caller cannot guess that. It cannot be used when the offset can be missing. DateTime::parse_from_rfc2822 and DateTime::parse_from_rfc3339 are similar but for well-known formats.

  3. Offset::datetime_from_str is similar but returns DateTime of given offset. When the explicit offset is missing from the input, it simply uses given offset. It issues an error when the input contains an explicit offset different from the current offset.

More detailed control over the parsing process is available via format module.

use chrono::prelude::*;

let dt = Utc.ymd(2014, 11, 28).and_hms(12, 0, 9);
let fixed_dt = dt.with_timezone(&FixedOffset::east(9*3600));

// method 1
assert_eq!("2014-11-28T12:00:09Z".parse::<DateTime<Utc>>(), Ok(dt.clone()));
assert_eq!("2014-11-28T21:00:09+09:00".parse::<DateTime<Utc>>(), Ok(dt.clone()));
assert_eq!("2014-11-28T21:00:09+09:00".parse::<DateTime<FixedOffset>>(), Ok(fixed_dt.clone()));

// method 2
assert_eq!(DateTime::parse_from_str("2014-11-28 21:00:09 +09:00", "%Y-%m-%d %H:%M:%S %z"),
           Ok(fixed_dt.clone()));
assert_eq!(DateTime::parse_from_rfc2822("Fri, 28 Nov 2014 21:00:09 +0900"),
           Ok(fixed_dt.clone()));
assert_eq!(DateTime::parse_from_rfc3339("2014-11-28T21:00:09+09:00"), Ok(fixed_dt.clone()));

// method 3
assert_eq!(Utc.datetime_from_str("2014-11-28 12:00:09", "%Y-%m-%d %H:%M:%S"), Ok(dt.clone()));
assert_eq!(Utc.datetime_from_str("Fri Nov 28 12:00:09 2014", "%a %b %e %T %Y"), Ok(dt.clone()));

// oops, the year is missing!
assert!(Utc.datetime_from_str("Fri Nov 28 12:00:09", "%a %b %e %T %Y").is_err());
// oops, the format string does not include the year at all!
assert!(Utc.datetime_from_str("Fri Nov 28 12:00:09", "%a %b %e %T").is_err());
// oops, the weekday is incorrect!
assert!(Utc.datetime_from_str("Sat Nov 28 12:00:09 2014", "%a %b %e %T %Y").is_err());

Again : See format::strftime documentation for full syntax and list of specifiers.

Conversion from and to EPOCH timestamps

Use Utc.timestamp(seconds, nanoseconds) to construct a DateTime<Utc> from a UNIX timestamp (seconds, nanoseconds that passed since January 1st 1970).

Use DateTime.timestamp to get the timestamp (in seconds) from a DateTime. Additionally, you can use DateTime.timestamp_subsec_nanos to get the number of additional number of nanoseconds.

// We need the trait in scope to use Utc::timestamp().
use chrono::{DateTime, TimeZone, Utc};

// Construct a datetime from epoch:
let dt = Utc.timestamp(1_500_000_000, 0);
assert_eq!(dt.to_rfc2822(), "Fri, 14 Jul 2017 02:40:00 +0000");

// Get epoch value from a datetime:
let dt = DateTime::parse_from_rfc2822("Fri, 14 Jul 2017 02:40:00 +0000").unwrap();
assert_eq!(dt.timestamp(), 1_500_000_000);

Individual date

Chrono also provides an individual date type (Date). It also has time zones attached, and have to be constructed via time zones. Most operations available to DateTime are also available to Date whenever appropriate.

use chrono::prelude::*;
use chrono::offset::LocalResult;

assert_eq!(Utc::today(), Utc::now().date());
assert_eq!(Local::today(), Local::now().date());

assert_eq!(Utc.ymd(2014, 11, 28).weekday(), Weekday::Fri);
assert_eq!(Utc.ymd_opt(2014, 11, 31), LocalResult::None);
assert_eq!(Utc.ymd(2014, 11, 28).and_hms_milli(7, 8, 9, 10).format("%H%M%S").to_string(),
           "070809");

There is no timezone-aware Time due to the lack of usefulness and also the complexity.

DateTime has date method which returns a Date which represents its date component. There is also a time method, which simply returns a naive local time described below.

Naive date and time

Chrono provides naive counterparts to Date, (non-existent) Time and DateTime as NaiveDate, NaiveTime and NaiveDateTime respectively.

They have almost equivalent interfaces as their timezone-aware twins, but are not associated to time zones obviously and can be quite low-level. They are mostly useful for building blocks for higher-level types.

Timezone-aware DateTime and Date types have two methods returning naive versions: naive_local returns a view to the naive local time, and naive_utc returns a view to the naive UTC time.

Limitations

Only proleptic Gregorian calendar (i.e. extended to support older dates) is supported. Be very careful if you really have to deal with pre-20C dates, they can be in Julian or others.

Date types are limited in about +/- 262,000 years from the common epoch. Time types are limited in the nanosecond accuracy.

Leap seconds are supported in the representation but Chrono doesn't try to make use of them. (The main reason is that leap seconds are not really predictable.) Almost every operation over the possible leap seconds will ignore them. Consider using NaiveDateTime with the implicit TAI (International Atomic Time) scale if you want.

Chrono inherently does not support an inaccurate or partial date and time representation. Any operation that can be ambiguous will return None in such cases. For example, "a month later" of 2014-01-30 is not well-defined and consequently Utc.ymd(2014, 1, 30).with_month(2) returns None.

Non ISO week handling is not yet supported. For now you can use the chrono_ext crate (sources).

Advanced time zone handling is not yet supported. For now you can try the Chrono-tz crate instead.

GitHub

https://github.com/chronotope/chrono
Comments
  • 1. Bump time to 0.3

    Fixes https://github.com/chronotope/chrono/issues/553, https://github.com/chronotope/chrono/pull/567

    This updates the time dependency to 0.3. The crate has been refactored to follow time API changes.

    This includes not-yet-merged changes made in https://github.com/chronotope/chrono/pull/567.

    Tasks:

    • [x] Bump time to 0.3 when released (see https://github.com/time-rs/time/issues/248)
    • [x] Refactor codebase for time API changes
    • [x] Fix test naive::date::tests::test_date_add (failing case)
    • [x] Fix test naive::datetime::tests::test_datetime_add (failing case)
    • [x] Have you added yourself and the change to the changelog? (Don't worry about adding the PR number)
    Reviewed by timvisee at 2021-07-29 15:27
  • 2. Locales

    Closes #199 Closes #153

    I made a pure Rust lib without any dependency that has the locales from glibc. It does not depend on glibc. It's using the locale data files from glibc.

    % This file is part of the GNU C Library and contains locale data.
    % The Free Software Foundation does not claim any copyright interest
    % in the locale data contained in this file.  The foregoing does not
    % affect the license of the GNU C Library as a whole.  It does not
    % exempt you from the conditions of the license if your use would
    % otherwise be governed by that license.
    

    I contacted the FSF and they seem to allow the use of these data:

    In short, we believe these files aren't copyrightable; for more background, please check https://sourceware.org/ml/libc-locales/2013-q1/msg00048.html

    -- I am not a lawyer, this is not a legal advice.

    The PR is a draft, I'm waiting for your feedback before finishing it.

    Reviewed by cecton at 2020-07-11 13:09
  • 3. Add initial support for the `wasm32` arch

    Building on PR #286, this PR adds initial support to chrono for the wasm32 architecture. Specifically, it adds wasm32-compatible versions of the Local::now() and Utc::now() constructors.

    EDIT: merging this would allow this issue to be closed as well.

    Reviewed by jjpe at 2018-11-04 22:38
  • 4. supported timezone syntax for DateTime from string

    I'm trying to accommodate the default timezone syntax returned from postgresql. It seems to provide an abbreviated form that chrono may not support-- it omits 00 minutes. Is there support for this in Chrono?

    http://play.integer32.com/?gist=b6394d764deb6a4bcf7b1b5ebd038969&version=stable

    extern crate chrono;
    use chrono::prelude::*;
    use chrono::DateTime;
    
    fn main() {
        let dt = "2018-02-06 11:17:09.534889-05";
        let test = DateTime::parse_from_str(dt, "%Y-%m-%d %H:%M:%S%.6f-%z");
        println!("{:?}", test);                                        
    }
    
    
    Reviewed by Dowwie at 2018-02-07 14:07
  • 5. Better usage of SemVer

    The upgrade from 0.3.0 to 0.3.1 broke several of my projects because the dependency on serde 0.9 to 1.0 caused API incompatibilities. It would be nice if you guys were more mindful of this in the future.

    Reviewed by heartsucker at 2017-05-05 12:29
  • 6. bump time

    • bump time
    • bump changelog

    Thanks for contributing to chrono!

    • [x] Have you added yourself and the change to the changelog? (Don't worry about adding the PR number)
    • [x] If this pull request fixes a bug, does it add a test that verifies that we can't reintroduce it?
    Reviewed by Milo123459 at 2021-12-29 22:06
  • 7. Optionally remove time crate dependency

    I would like to use the chrono crate to process time information on systems that don't have a clock. The time crate, which is used by chrono to obtain and represent the local time, can't be made to work on such a system. This PR adds a default-enabled "local" feature to the crate and moves all code that is dependent on the time crate behind a cfg-gate. Current users of chrono need to do nothing. Users of chrono that would like to use it without the time crate can set default-features = false in their Cargo.toml.

    Open questions:

    • Test coverage I have fixed all unit tests such that they will pass with or without the local feature. There are however 31 doc tests that use some code that has been cfged-out. I'm not sure how to selectively disable them.
    • UTC UTC::now and UTC::today also depend on the time crate. I have put them behind the same cfg-gate, but that might be a misnomer. We could leave this as is, or I could add another feature with a different name or rename the current feature.
    Reviewed by jethrogb at 2017-02-24 23:31
  • 8. basic wasm support

    previous PRs toward wasm support appear stuck ( https://github.com/chronotope/chrono/pull/287 and https://github.com/chronotope/chrono/pull/286 - the refactor it depended on ).

    I built on the essentials of the work by @jjpe, fixing the local timezone support and adding tests.

    Reviewed by evq at 2019-08-16 09:43
  • 9. CVE-2020-26235

    Please update time dependency.

    Inverse Dependency graph time 0.1.44 (registry+https://github.com/rust-lang/crates.io-index) └── chrono 0.4.19 (registry+https://github.com/rust-lang/crates.io-index)

    Reviewed by acim at 2021-10-11 17:05
  • 10. Implement Support for no_std

    This adds a new std feature to chrono that is enabled by default. By deactivating this feature via default-features = false you can now use chrono in applications that don't use the standard library. The serde feature is supported as well.

    Resolves #336

    Reviewed by CryZe at 2019-09-07 10:16
  • 11. Absorb the time crate

    I've discussed this with one of the time crate maintainers (Alex Chrichton), and with his blessing I've purged the dependency on the deprecated time crate in favor of folding its code into chrono. See issue #285.

    This enables further refactoring.

    Reviewed by jjpe at 2018-11-02 19:25
  • 12. RFC: Timezone information lost in a myriad of places

    Hello! I have found myself here after a long, winding road trying to solve a relatively simple problem. This has led me to designing a library that does something very simple: one that takes a real time (for the sake of the argument; a DateTime<FixedOffset>) and waits on it.

    Ok! Lets try writing it

    pub fn sleep_until(time: DateTime<FixedOffset>) {
        while time < Utc::now() {
            sleep();
        }
    }
    

    if we look at the source of chrono, it turns out that the PartialOrd implementation being used disregards all timezone information, and only compares the underlying NaiveDateTime data. Thus, this would be incorrect if the current date time is not UTC.

    Ok, lets try again, this time converting first:

    pub fn sleep_until(time: DateTime<FixedOffset>) {
        let time = time.with_timezone(&Utc);
        while time < Utc::now() {
            sleep();
        }
    }
    

    except with_timezone doesn't actually change the underlying date either, it just renames the timezone. So we have the same issue here.


    This is a date-time library and when I'm writing programs/libraries/etc I expect date-times to represent real, precise moments of time However DateTime in this library seems to be little more that NaiveDateTime with a very meaningless timezone component.

    In my opinion, this library should use Rust's strict type system to restrict two DateTimes from ever being compared; or converted-between without considering the concrete (including timezone) moments that they represent. This library already provides the NaiveDateTime interface, which can give the user liberty to convert between DateTime objects without considering their timezone, but this shouldn't be the primary operation that is hidden from the user.

    Please let me know if this is the correct place to be having this discussion, and if this library is even correct for representing "real wall times" (but if not, what is?).

    Reviewed by 4e554c4c at 2022-05-28 04:05
  • 13. Improve docs about NaiveDateTime conversion

    This adds some basic explanation on how to convert a NaiveDateTime to a DateTime.

    Thanks for contributing to chrono!

    • [x] Have you added yourself and the change to the changelog? (Don't worry about adding the PR number)
    • [ ] If this pull request fixes a bug, does it add a test that verifies that we can't reintroduce it?
    Reviewed by gerritsangel at 2022-05-07 13:38
  • 14. Make conversion from NaiveDateTime to DateTime easier

    Hello,

    I noticed that the conversion from a NaiveDateTime to a DateTime by supplying a TimeZone is not really as easy as it could be (or IDE-friendly).

    Mostly, I think the problem is that you have the conversion method on the TimeZone trait, instead of on the NaiveDateTime object. At least speaking for myself, if I want to convert a NaiveDateTime, I already have one (e.g. because I manually parsed it from somewhere without Time information) and then just want to supply the TimeZone object. As a normal developer, I would just press . on the object and hope that my IDE will display me a suitable method.

    Therefore, what about something like this?

    impl NaiveDateTime {
        pub fn to_datetime_local<Tz: TimeZone>(&self, tz: Tz) -> LocalResult<DateTime<Tz>> {
            tz.from_local_datetime(self)
        }
    }
    

    This makes it really obvious how to construct a DateTime from a NaiveDateTime:

    #[test]
    fn test_naivedatetime_to_local() {
        let offset = FixedOffset::east(3600);
        let dt = NaiveDate::from_ymd(2022,05,07).and_hms(14,51,00)
            .to_datetime_local(offset);
        assert_eq!("2022-05-07T14:51:00+01:00", dt.single().unwrap().to_rfc3339());
    }
    

    Furthermore, while the LocalResult is of course correct, I think it would be nice to have some kind of "lossy" output. I would assume that most of the time there is only one result (as the DST transitions are mostly in the night anyway, where they have the least impact). Currently the user has to handle this situation every time, while most of the time the conversion will be correct. Anyway, I think it would be good for a time library to have some sensible default how to work with this, as not every user might know what to do in this case.

    I checked on the Java time API, and they handle it like this (https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html#atZone-java.time.ZoneId-):

    In most cases, there is only one valid offset for a local date-time. In the case of an overlap, where clocks are set back, there are two valid offsets. This method uses the earlier offset typically corresponding to "summer".

    In the case of a gap, where clocks jump forward, there is no valid offset. Instead, the local date-time is adjusted to be later by the length of the gap. For a typical one hour daylight savings change, the local date-time will be moved one hour later into the offset typically corresponding to "summer".

    To obtain the later offset during an overlap, call ZonedDateTime.withLaterOffsetAtOverlap() on the result of this method. To throw an exception when there is a gap or overlap, use ZonedDateTime.ofStrict(LocalDateTime, ZoneOffset, ZoneId).

    Why not create an additional method on LocalResult which returns something like the Java handling (not quite sure how other time libraries handle this situation)?

    Reviewed by gerritsangel at 2022-05-07 13:10
  • 15. Fix parse panic

    This is to resolve #645. The test was previously panicking when subtracting the FixedOffset from the NaiveDateTime. There may be other places that use that subtraction that we want to look at in the future.

    Reviewed by botahamec at 2022-05-05 20:08
A simple and fun way to view the time!
A simple and fun way to view the time!

Concentric Time A simple and fun way to view the time! Screenshots Dark mode Light mode Dev This project uses Dioxus (a Rust-Wasm framework) and does

Apr 27, 2022
Time series anomaly detection for Rust

AnomalyDetection.rs Time series AnomalyDetection for Rust Learn how it works Installation Add this line to your application’s Cargo.toml under [depend

Jan 4, 2022
A set of tools for generating signed exchanges at serve time.

sxg-rs sxg-rs is a set of tools for generating signed exchanges at serve time: cloudflare_worker runs on Cloudflare Workers. fastly_compute runs on Fa

May 24, 2022
datez: convert a time into several timezones

datez: convert a time into several timezones In July, when it is 16:00 in Canberra, what time is it in Caracas, and where I am in Cambridge? $ datez 2

Nov 17, 2021
Get unix time (nanoseconds) in blazing low latency with high precision

RTSC Get unix time (nanoseconds) in blazing low latency with high precision. About 5xx faster than SystemTime::now(). Performance OS CPU benchmark rts

Feb 28, 2022
Generate perfect code headers every time.

Generate perfect code headers every time.

May 26, 2022
eos is a datetime library for Rust, aimed at being robust, simple, and easy to use

eos eos is a datetime library for Rust, aimed at being robust, simple, and easy to use. eos is made with the assumption of operating under a proleptic

May 13, 2022
A pure Rust reimplementation of libc functions localtime, gmtime and mktime.

tz-rs A pure Rust reimplementation of libc functions localtime, gmtime and mktime. This crate allows to convert between a Unix timestamp and a calenda

May 5, 2022
This crate provides high-performance formatting and parsing routines for ISO8061 timestamps

ISO8061 Timestamp This crate provides high-performance formatting and parsing routines for ISO8061 timestamps, primarily focused on UTC values but wit

Apr 21, 2022
The implementation of the Persian (Solar Hijri) Calendar in Rust

Rust Persian Calendar Rust Persian Calendar v0.1.1 provides functionality for conversion among Persian (Solar Hijri) and Gregorian calendars. A Julian

Mar 5, 2022
Cocom - NTP client written in Rust

Cocom is an implementation of the NTP-protocol, to receive the time from NTP-server. The client does not necessarily need arguments.

Nov 26, 2021
Date and time library for Rust

Chrono: Date and Time for Rust It aims to be a feature-complete superset of the time library. In particular, Chrono strictly adheres to ISO 8601. Chro

May 25, 2022
Easy, Simple, Clean. Making status bars reliable and up-to-date.

Simple Status Easy, Simple, Clean. Making status bars reliable and up-to-date. Installation Compiling simple_status yourself doesn't require much. Ins

Feb 21, 2022
httm prints the size, date and corresponding locations of available unique versions of files residing on ZFS snapshots

httm prints the size, date and corresponding locations of available unique versions of files residing on ZFS snapshots, as well as allowing their interactive viewing and restoration.

May 15, 2022
Rust TLS/SSL certificate expiration date from command-line checker

Rust TLS/SSL certificate expiration date from command-line checker

Apr 12, 2022
A cargo subcommand for displaying when Rust dependencies are out of date

cargo-outdated Linux: A cargo subcommand for displaying when Rust dependencies are out of date About cargo-outdated is for displaying when dependencie

May 15, 2022
Keep your dependencies up-to-date
Keep your dependencies up-to-date

Deps.rs - Dependency status at a glance Deps.rs is a service that shows you at a glance if any of your dependencies are out of date or insecure. This

May 15, 2022
Retrieve the expiration date of an X509 certificate from a host's certificate handshake

certificate-expiration-retriever Retrieve the expiration date of an X509 certificate from a host's certificate handshake certificate-expiration-retrie

Feb 27, 2022
`fugit` provides a comprehensive library of `Duration` and `Instant` for the handling of time in embedded systems, doing all it can at compile time.

fugit fugit provides a comprehensive library of Duration and Instant for the handling of time in embedded systems, doing all it can at compile time. T

Apr 27, 2022
Scalable and fast data store optimised for time series data such as financial data, events, metrics for real time analysis

OnTimeDB Scalable and fast data store optimised for time series data such as financial data, events, metrics for real time analysis OnTimeDB is a time

Apr 5, 2022