Crates.io | chrono-wasi |
lib.rs | chrono-wasi |
version | 0.4.11 |
source | src |
created_at | 2020-01-27 17:59:07.815923 |
updated_at | 2023-01-22 20:21:16.332267 |
description | Date and time library for Rust |
homepage | https://github.com/chronotope/chrono |
repository | https://github.com/chronotope/chrono |
max_upload_size | |
id | 202460 |
size | 823,107 |
It aims to be a feature-complete superset of the time library. In particular,
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.
Put this in your Cargo.toml
:
[dependencies]
chrono = "0.4"
Or, if you want Serde include the feature like this:
[dependencies]
chrono = { version = "0.4", features = ["serde"] }
Then put this in your crate root:
extern crate chrono;
Avoid using use chrono::*;
as Chrono exports several modules other than types.
If you prefer the glob imports, use the following instead:
use chrono::prelude::*;
Chrono currently uses
the Duration
type
in the time
module to represent the magnitude of a time span.
Since this has the same name to 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.
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.
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
SystemTime
,
which tracks your system clock, or
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 TimeZone
s into this type.
DateTime
s 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:
extern crate 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 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.
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("%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:
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.
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.
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.
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);
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.
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.
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
.
Advanced time zone handling is not yet supported. For now you can try the Chrono-tz crate instead.