Recalculating voting schedule should be called first when setting a new consensus
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 #23623 (moved):
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.