Crates.io | jiff |
lib.rs | jiff |
version | |
source | src |
created_at | 2024-02-17 18:34:44.638963 |
updated_at | 2024-11-30 15:17:29.696233 |
description | A date-time library that encourages you to jump into the pit of success. This library is heavily inspired by the Temporal project. |
homepage | |
repository | https://github.com/BurntSushi/jiff |
max_upload_size | |
id | 1143399 |
Cargo.toml error: | TOML parse error at line 23, column 1 | 23 | autolib = false | ^^^^^^^ unknown field `autolib`, expected one of `name`, `version`, `edition`, `authors`, `description`, `readme`, `license`, `repository`, `homepage`, `documentation`, `build`, `resolver`, `links`, `default-run`, `default_dash_run`, `rust-version`, `rust_dash_version`, `rust_version`, `license-file`, `license_dash_file`, `license_file`, `licenseFile`, `license_capital_file`, `forced-target`, `forced_dash_target`, `autobins`, `autotests`, `autoexamples`, `autobenches`, `publish`, `metadata`, `keywords`, `categories`, `exclude`, `include` |
size | 0 |
Jiff is a datetime library for Rust that encourages you to jump into the pit of success. The focus of this library is providing high level datetime primitives that are difficult to misuse and have reasonable performance. Jiff supports automatic and seamless integration with the Time Zone Database, DST aware arithmetic and rounding, formatting and parsing zone aware datetimes losslessly, opt-in Serde support and a whole lot more.
Jiff takes enormous inspiration from Temporal, which is a TC39 proposal to improve datetime handling in JavaScript.
Dual-licensed under MIT or the UNLICENSE.
chrono
, time
, hifitime
and icu
Here is a quick example that shows how to parse a typical RFC 3339 instant, convert it to a zone aware datetime, add a span of time and losslessly print it:
use jiff::{Timestamp, ToSpan};
fn main() -> Result<(), jiff::Error> {
let time: Timestamp = "2024-07-11T01:14:00Z".parse()?;
let zoned = time.intz("America/New_York")?.checked_add(1.month().hours(2))?;
assert_eq!(zoned.to_string(), "2024-08-10T23:14:00-04:00[America/New_York]");
// Or, if you want an RFC3339 formatted string:
assert_eq!(zoned.timestamp().to_string(), "2024-08-11T03:14:00Z");
Ok(())
}
There are many more examples in the documentation.
Jiff is on crates.io and can be
used by adding jiff
to your dependencies in your project's Cargo.toml
.
Or more simply, just run cargo add jiff
.
Here is a complete example that creates a new Rust project, adds a dependency
on jiff
, creates the source code for a simple datetime program and then runs
it.
First, create the project in a new directory:
$ mkdir jiff-example
$ cd jiff-example
$ cargo init
Second, add a dependency on jiff
:
$ cargo add jiff
Third, edit src/main.rs
. Delete what's there and replace it with this:
use jiff::{Unit, Zoned};
fn main() -> Result<(), jiff::Error> {
let now = Zoned::now().round(Unit::Second)?;
println!("{now}");
Ok(())
}
Fourth, run it with cargo run
:
$ cargo run
Compiling jiff v0.1.0 (/home/andrew/rust/jiff)
Compiling jiff-play v0.1.0 (/home/andrew/tmp/scratch/rust/jiff-play)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 1.37s
Running `target/debug/jiff-play`
2024-07-10T19:54:20-04:00[America/New_York]
The first time you run the program will show more output like above. But subsequent runs shouldn't have to re-compile the dependencies.
Jiff has several crate features for customizing support for Rust's standard
library, serde
support and whether to embed a copy of the Time Zone Database
into your binary.
The "crate features" section of the documentation lists the full set of supported features.
My plan is to iterate on the Jiff API and make occasional breaking change releases over the next ~year. Assuming API breaking changes have settled down after about one year's time, my plan will be to release Jiff 1.0 and commit to the API for a long period of time. (Measured, at least, in years.)
The purpose of this plan is to get Jiff to a 1.0 stable state as quickly as possible. The reason is so that others feel comfortable relying on Jiff as a public dependency that won't cause ecosystem churn.
The most important design goal of Jiff is to be a high level datetime library
that makes it hard to do the wrong thing. Second to that is performance. Jiff
should have reasonable performance, but there are likely areas in which it
could improve. See the bench
directory for benchmarks.
The question of platform support in the context of datetime libraries comes up primarily in relation to time zone support. Specifically:
Antarctica/Troll
?Both of these require some level of platform interaction.
For discovering time zone transition data, Jiff relies on the
IANA Time Zone Database. On Unix systems, this is usually found at
/usr/share/zoneinfo
, although it can be configured via the TZDIR
environment variable (which Jiff respects). On Windows, Jiff will automatically
embed a copy of the time zone database into the compiled library.
For discovering the system time zone, Jiff reads /etc/localtime
on Unix. On
Windows, Jiff reads the Windows-specific time zone identifier via
GetDynamicTimeZoneInformation
and then maps it to an IANA time zone
identifier via Unicode's CLDR XML data.
I expect Jiff to grow more support for other platforms over time. Please file issues, although I will likely be reliant on contributor pull requests for more obscure platforms that aren't easy for me to test.
For more on platform support, see PLATFORM.md
.
At time of writing, it is no accident that Jiff has zero dependencies on Unix. In general, my philosophy on adding new dependencies in an ecosystem crate like Jiff is very conservative. I consider there to be two primary use cases for adding new dependencies:
windows-sys
for discovering the system time zone on
Windows.serde
.
But even here, I expect to be conservative, where I'm generally only willing
to depend on things that have fewer breaking change releases than Jiff.A secondary use case for new dependencies is if Jiff gets split into multiple
crates. I did a similar thing for the regex
crate for very compelling
reasons. It is possible that will happen with Jiff as well, although there are
no plans for that. And in general, I expect the number of crates to stay small,
if only to make keep maintenance lightweight. (Managing lots of semver API
boundaries has a lot of overhead in my experience.)
This crate's minimum supported rustc
version is 1.70.0
.
The policy is that the minimum Rust version required to use this crate can be
increased in minor version updates. For example, if jiff 1.0 requires Rust
1.20.0, then jiff 1.0.z for all values of z
will also require Rust 1.20.0 or
newer. However, jiff 1.y for y > 0
may require a newer minimum version of
Rust.