PAPaul-E·Aug 1, 2026Submission
Soft-deprecating chrono and chrono-tz
3 points · Open discussionchronotope
chrono
Rust2015–2026
chronotope / chrono
chrono
Date and time library for Rust
9Distinct people
12Mentions
0Explicit recommenders
4KGitHub stars
What to know before exploring
What it is
Date and time library for Rust
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- time-rs/time · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year12 dated mentions
Observed mentions: 2015-01-24 20:34:26 UTC to 2026-08-01 20:39:31 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 1 | 0 |
What Hacker News says
12 sourcesI independently arrived at the same conclusion and implemented the excess tv_nsec proposal to Chrono [1] back when I first designed it. This decision remains controversial to this day for several good reasons, unfortunately [2].
[1] https://docs.rs/chrono/latest/chrono/naive/struct.NaiveTime....
[2] https://github.com/chronotope/chrono/issues/954
In The Unix leap second messThe problem is that this effects higher languages too, because they often build on libc. And on some OSes, they don't have a choice, because the system call interface is unstable and/or undocumented).
For example in rust, multiple time libraries were found to be unsound if `std::env::set_env` was ever called from a multi-threaded program. See:
https://github.com/time-rs/time/issues/293 and https://github.com/chronotope/chrono/issues/499
https://github.com/rust-lang/rust/issues/27970
https://github.com/rust-lang/rust/issues/90308
In Getaddrinfo() on glibc calls getenv(), oh boyI've spent the last several weeks porting a backend I had written in Go over to Rust (using Axum) and so far so good. But I don't know if I can call things in the Rust world like Axum/Actix/etc. "frameworks" anymore considering all the time I've had to spend researching/vetting crates to get the same functionality that comes out of the box in Spring/ASP.net/Django/etc.
Take handling datetimes for example. Do I use time or chrono? The initial developer/maintainer of chrono left[1] and for the longest time the crate was unmaintained while a CVE remained open[2] until a new maintainer finally came along and addressed it (I think?). All right, so, time it is then... but it uses its own custom format specifiers[3] that I had to get used to coming from the more familiar strftime used by other languages.
Or how about input/form validation. One o
Read the rest
f the most popular crates for that, validator, had its maintainer admit that they don't even use it themselves?[4] Of course I can already hear people yelling at me, "well, why don't you contribute then?!", and I certainly would love to if I could! But I have to finish what's in front of me first.
That being said, I still very much enjoy using Rust. Maybe less so for web-related projects. I just have to stay on an even keel despite the growing hype.
[1]: https://old.reddit.com/r/rust/comments/qamgyh/is_the_chrono_...
[2]: https://github.com/chronotope/chrono/issues/602
[3]: https://time-rs.github.io/book/api/format-description.html#v...
[4]: https://github.com/Keats/validator/issues/201
> I think library authors should be more relentless and break compatibility every few years. We just need some conventions to not do so very often.
I indeed did this years ago---I'm the original author of Chrono [1]---and it wasn't well received [2] [3] [4]. To be fair, I knew it was a clear violation of semantic versioning but I didn't see any point of strictly obeying that until we've reached 1.0 so I went ahead. People complained a lot and I had to yank the release in question. By then I realized many enough people religiously expect semantic versioning (for good reasons though) and it's wiser to avoid useless conflict.
[1] https://github.com/chronotope/chrono
[2] https://github.com/chronotope/chrono/issues/146#issuecomment...
[3] https://github.com/chronotope/chrono/issues/156
[4] https://github.com/chronotope/chrono/blob/main/CHANGEL
Read the rest
Chrono – Date and time library for rust
1 points · Open discussionHah, reminds me of this issue where 90% of the content is spam: https://github.com/chronotope/chrono/issues/499
In Improving GitHub Code SearchThat is a trade-off, as the team typically needs a common vision that might not be easy to distribute (or even extract out of your mind).
I had a similar problem with Chrono [1], the most popular Rust date & time library at the moment (though now rivalled by time-rs [2] ;-), where I was struggling with personal issues and yet (thus?) unable to sufficiently materialize my vision. Eventually I gave up and passed a torch to other interested people, one of which is now the primary maintainer, but no major API design and stabilization that would lead to the 1.0 is not happening as far as I concern.
[1] https://github.com/chronotope/chrono/
[2] https://github.com/time-rs/time
In Actix Web – Project Future> The easiest way to code it is to just precompute the year % 400 table and report the results.
If you are interested, Chrono [1] internally uses the exact table. Constants there refer to dominical letters [2].
[1] https://github.com/chronotope/chrono/blob/a4488007272569f752...
[2] https://en.wikipedia.org/wiki/Dominical_letter
In When Can I Reuse This Calendar?This is something I've seen, but does it apply to chrono? I'm looking at its README on GitHub (https://github.com/chronotope/chrono), and useful examples are right there up front.
DateTime::format seems to do the same thing as strftime, with a format string parsed at run-time.
In Rocket, Rust Web Framework, v0.2: Managed State and MoreSome of your criticisms are good and valid, but
> Sorting out what was returned requires a "match" statement, which is rather verbose
is particularly low quality: even the code you quote above demonstrates (or at least hints) that this isn't true. `Option` provides a variety of combinator methods that avoid the need for manual pattern matching: http://doc.rust-lang.org/nightly/std/option/enum.Option.html
Also, this isn't extremely true either:
> Note that none of this code does any computation. It's all field access and update
Doesn't accessing fields and updating them count as computation? Anyway, nothing in date/time handling is just field access and updating; time libraries are hard (and I'm very happy that lifthrasiir is tackling it, their libraries are always high-quality and diligently written). There's actual "real" computation hap
Read the rest
pening, you can see this looking at the underlying implementation: https://github.com/lifthrasiir/rust-chrono/blob/cf5e2f322fbc... (and tracking those functions calls through inside that module).
That's a legitimate criticism. As of yesterday, how to convert "String" to "&str" still wasn't nailed down. (".as_string(), or "&[]"?). Things are far better than they were a month ago, though.
After using Rust a little, I get the feeling that the borrow system, the big innovation, is in good shape. The type system is clunky. Take a look at this date/time module:
https://github.com/lifthrasiir/rust-chrono/blob/master/src/d...
Note that none of this code does any computation. It's all field access and update. It's not a multi-calendar system with time zone tables. This is the code for stuffing the year into a Datetime object:
#[inline]
fn with_year(&self, year: i32) -> Option<DateTime<Off>> {
self.local().with_year(year).and_then(|datetime|
self.offset.from_local_datetime(&datetime).single())
}
This has generi
Read the rest
cs and a closure, neither of which ought to be necessary. Despite all this generality, there are two copies of this code, one for time-zone aware and one for "naive" timestamps. The author of that module has misgivings about the structure. He writes "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." This is the best of the three date-time modules available; the other two won't even compile with the current build system and are abandoned.
There are some neat ideas in the type system. One is that if you have something which might not be able to return a value, you have it return an "Option<T>" value, which can have a value of type T, or a value of None. Sorting out what was returned requires a "match" statement, which is rather verbose. It's an elegant way to avoid null pointers and error codes, but it's quite verbose in practice. The business with "and_then" and the closure above is to deal with that problem. See "Option Monads in Rust" ("http://www.hoverbear.org/2014/08/12/option-monads-in-rust/") for an explanation.
In Python, situations like this raise a ValueError exception. In Go, situations like this return (uselessvalue, err). The Rust solution is formally correct, but complex and verbose for what it's doing.
I'm worried that all this verbiage will turn new users off. It turns me off, and I have a background in formal systems.