time VS bitvec

// 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());

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

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.

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.

Upgrade time to 0.3

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.

link to source code

I was also under the false impression that bitwise encoding was slow. When I first implemented bitcode with bitvec I got performance 20x worse than bincode. After writing my own implementation I was able to get much better performance.

interesting; i'll have to compare this to my rust counterpart. your numbers indicate some clever implementations i'd love to read

Not to mention having a lackluster std which causes you to use nonstardard not so well documented crates and a 40K LoC library to do "bit-twiddling" (the lib, https://github.com/bitvecto-rs/bitvec the blog that says "twiddle bits" https://blog.adamchalmers.com/making-a-dns-client/ and for crying out loud the blogger also used the language the author mentioned and I quote "ergonomics AND speed AND correctness")

https://github.com/bitvecto-rs/bitvec/issues/135 is a very funny read about how to perform inttoptr with provenance retention

Technically #135 gives me license to yank affected crates, but since the only exploit is "Miri crashes exactly one test out of the suite" it's not really worth it to be a stickler. Call it a truce

My friend Nika wrote a macro that packs a sequence of 1, 0, … tokens into a correctly structured bit-buffer, adaptable over any register type or bit-ordering, at compile time. It's now basically this whole file

if you are interested in a user manual, you can use mdbook as well. for an example, my bitvec project uses mdbook (book.toml) and a github action (.github/workflows/gh-pages.yml) to compile the guide and host it as a github pages website. it's slightly more complicated, and i'd like docs.rs to follow hexdoc.pm's example of hosting both api docs and prose, but until then this is a pretty reasonable solution.

the first one

i would browse the standard library, tower, nom, or my own bitvec to see layout and trait/record separation. in particular, std::io and std::net may be of use: io::Read and io::Write are pervasive examples of implementing unixy file-descriptor-like behavior in the type system