mirrors/arti.git/crates/tor-netdir/src/hsdir_params.rs, branch arti-v2.1.0

Fix name of clippy lint to unchecked_time_subtraction (2)

2025-11-06T11:28:22Z

Run maint/add_warning

tor-netdoc: Apply much rustfmt churn

2025-08-26T09:41:21Z

tor-netdoc: Remove generics from Consensus and its contents

2025-08-26T09:41:21Z

tor-netdoc: netstatus: Move everything variety-specific

2025-08-26T09:41:21Z

This is much code motion. This splits many types into two. For example, `Conensus` is now`plain::Consensus` and `md::Consensus`. We're going to get rid of the generics later in this branch.

Switch Cargo.toml files to edition 2024.

2025-08-07T15:28:36Z

First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again.

Resolve clippy::empty_line_after_doc_comments warnings.

2024-12-03T14:27:29Z

These are new in Rust 1.83.

Run maint/add_warning.

2024-03-13T16:30:53Z

Fix typos in doc comments

2024-03-06T19:52:42Z

tor-netdir: Add a unit test for HsDirParams::offset_within_srv_period.

2024-01-24T16:42:43Z

tor-hsservice: Make offset_within_srv_period() work with timestamps from newer periods.

2024-01-24T15:58:55Z

This fixes a bug where `offset_within_srv_period()` returns `None`, instead of the offset of `when` from the start of the SRV of the previous time period: ``` 2024-01-24T15:24:46Z ERROR tor_hsservice::svc::publish::reactor: descriptor upload failed for HS service allium-cepa2 and time period TimePeriod { interval_num: 19745, length: IntegerMinutes { value: 1440 }, epoch_offset_in_sec: 43200 }: error: Programming error: internal error (bug) at /../arti/crates/tor-hsservice/src/svc/publish/reactor.rs:218:13: current wallclock time not within SRV range?! (now=SystemTime { tv_sec: 1706109886, tv_nsec: 246572852 }, SRV_start=SystemTime { tv_sec: 1705968000, tv_nsec: 0 }) ``` We need to be able to calculate this offset even if `now` is not within the SRV range (because we upload the descriptor to the HsDirs of the *previous* time period too). Note a similar bug exited in `offset_within_period()` (which no longer exists) too! That one was fixed in !1744: ``` Hidden services can have multiple "active" time periods for which they generate descriptors. We need to be able to compute the offset of a timestamp from the start of a given time period, even if that timestamp falls within the "next" time period (for example, when publishing descriptors for the "previous" time period, the `when` timestamp will fall outside the `(start, end)` range of the "previous" time period). ```