In `networkstatus_set_current_consensus()`, at some point the `if (is_usable_flavor)` does a series of action on the newly set consensus. One of those is `nodelist_set_consensus()` which among many things will compute the HSv3 HSDir index for every `node_t` in this new consensus. That step requires the voting schedule object to be defined too compute time periods that the HS subsystem needs requiring the voting schedule timings. So, the very first thing we should do when we get a new usable consensus is set its voting schedule timings. That is call `dirvote_recalculate_timing(options, now);` which is currently after the nodelist set. This has been observed by this Bug when tor starts with the latest change in legacy/trac#23623: ``` Nov 07 15:39:09.364 [notice] Bootstrapped 0%: Starting Nov 07 15:39:09.978 [warn] tor_timegm(): Bug: Out-of-range argument to tor_timegm (on Tor 0.3.3.0-alpha-dev c6c4a421fd7d8a0d) Nov 07 15:39:09.978 [warn] dirvote_get_start_of_next_interval(): Bug: Ran into an invalid time when trying to find midnight. (on Tor 0.3.3.0-alpha-dev c6c4a421fd7d8a0d) ... ``` The other thing I wondered is if we should add a safe guard to the public function `dirvote_get_next_valid_after_time()` to calculate the timings in case the voting schedule is zeroed because in this case, this is where the issue comes from, that function returns 0.