chrono
time
Our great sponsors
chrono | time | |
---|---|---|
23 | 12 | |
3,126 | 1,010 | |
2.3% | 3.9% | |
9.7 | 8.7 | |
10 days ago | 7 days ago | |
Rust | Rust | |
GNU General Public License v3.0 or later | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
chrono
- The Unix leap second mess
-
Getaddrinfo() on glibc calls getenv(), oh boy
The 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
- Choosing the Right Rust Web Framework: An Overview
-
ZeroVer: 0-Based Versioning
> 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 obeying that until we've reached 1.0 so I went ahead. People complained a lot and I had to yank the problematic release. 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/CHANGELOG.md#...
-
Simple, fast and safety alternative for unzip
On that note, it would also be good to configure cargo-deny so that a CI pipeline and any maintainer can easily audit the current dependency versions. Sometimes CVEs require a new major semver (looking at you, time 0.1.x and thus chrono 0.4.x), so it's not enough to rely on people installing the tool with semver-compatible updates. Automatically auditing dependencies is really important, and given how easy cargo-deny makes it, I don't think many projects have any excuse not to configure it.
-
Is it unidiomatic/anti-pattern to use the return keyword ?
The example has been randomly taken from the [Chrono][https://github.com/chronotope/chrono/blob/main/src/offset/utc.rs] crate.
-
Will Rust drop dependency on libc and make direct system calls? when ? (Please don't mention no_std case)
libc isn't "just a wrapper". Is a massive legacy codebase filled with hacks, UBs and bugs: https://github.com/chronotope/chrono/issues/499
- chrono 0.4.20 has been released, fixing the RUSTSEC-2020-0159 issue
-
chrono 0.4.20-rc.1 has just been released!!
Would love to have people test this, you can leave feedback here: https://github.com/chronotope/chrono/issues/674.
-
Trying to learn about chrono, Duration, etc...
Security issues? I'm looking at the open issues, but haven't noticed any that seem to be security related (no security related labels either). What am I missing here?
time
-
Rust: Actix-web and Daily Logging
// To load RUST_LOG from .env file. dotenv().ok(); /* On Ubuntu 22.10, calling UtcOffset's offset methods causes IndeterminateOffset error!! See also https://github.com/time-rs/time/pull/297 ... */ // TO_DO: 11 is the current number of hours the Australian Eastern Standard Time (AEST) // is ahead of UTC. This value need to be worked out dynamically -- if it is at all // possible on Linux!! // let guard = init_app_logger(UtcOffset::from_hms(11, 0, 0).unwrap());
-
Getaddrinfo() on glibc calls getenv(), oh boy
The 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
- The time crate has officially adopted an N-2 MSRV policy for end-user improvements and an N-4 MSRV policy for internal improvements.
-
Simple, fast and safety alternative for unzip
On that note, it would also be good to configure cargo-deny so that a CI pipeline and any maintainer can easily audit the current dependency versions. Sometimes CVEs require a new major semver (looking at you, time 0.1.x and thus chrono 0.4.x), so it's not enough to rely on people installing the tool with semver-compatible updates. Automatically auditing dependencies is really important, and given how easy cargo-deny makes it, I don't think many projects have any excuse not to configure it.
- time: MSRV policy is changing beginning 2023-07-01 to N-2 rustc versions
-
Hifitime 3.5.0: time.rs and chrono alternative, only more precise, formally verified, and used in scientific and engineering programs
I've come to understand that correct support for leap seconds for time computations cannot be implemented in a reliable and globally consistent manner. Here is a GitHub discussion that touches on this.
-
What's new in SeaORM 0.9.0
Upgrade time to 0.3
-
What lightweight date/time library to use? [2022 edition]
I'm not fully aware of all the history but here's what I think happened: time 0.1 was originally a minimal wrapper around libc time functions, maintained by Alex Crichton. (I seem to remember it may have been part of the std library before 1.0, but I'm not sure about that part.) In August of 2016 it was declared to no longer be actively maintained, with the README stating bugs would still get fixed.
- What should we do about CVE-2020-26235 (localtime_r may be unsound)?
-
no_std with Error trait?
link to source code
What are some alternatives?
advisory-db - Security advisory database for Rust crates published through crates.io
bitvec - A crate for managing memory bit by bit
jelly-actix-web-starter - A starter template for actix-web projects that feels very Django-esque. Avoid the boring stuff and move faster.
bitsvec - A bit vector with the Rust standard library's portable SIMD API.
mozsearch - Mozilla code search website. (Please file bugs in bugzilla at https://mzl.la/2YtXmoN)
wyhash-rs - wyhash fast portable non-cryptographic hashing algorithm and random number generator in Rust
chat - A telnet chat server
uuid - Generate and parse UUIDs.
rusqlite - Ergonomic bindings to SQLite for Rust
binfarce - Extremely minimal parser for ELF/PE/Mach-o/ar
polystrip - A 2D accelerated graphics library for Rust
hifitime - A high fidelity time management library in Rust