I like the idea of using a fixed time window to get hashrate instead of a fixed number of blocks because it’s valid at the moment you run the query. This allows minor errors in timestamps from (usually) affecting the result. It also allows getting hashrates in the past at specific times such as a daily estimate at midnight. BTW the estimate isn’t at that time or height, but at the midpoint of the heights or time range from which you’re summing work.
Instead of adjusting by (N-1)/N, it might be as accurate to use the current time (of the query) in place of the most recent timestamp. If you run the query at random, it’s expected to be 1 blocktime since the most recent block, so it seems to work the same as applying (N-1)/N by making the timespan 1 block longer. This also allows me to get an estimate of hashrate at N=1 which is otherwise not possible due to the divide by zero. But by experiment and forcing timespan = 1 second if timespan < 1 second, for N=1 I get:
hashrate =~ difficulty * 2^32 / timespan / 6
BTW, an N-1 is also seen when estimating total chain work from the Nth lowest hashes ever seen. Interestingly, knowledge of difficulty and timestamps isn’t needed.
chain_work =~ 2^256 * (N-1) / Nth_lowest_hash
StdDev of the error =~ 1/SQRT(N-1) for N > 10
on the condition that difficulty target was never < Nth_lowest_hash and all orphans with low hashes are included (if needed) in N, but this also counts all orphans in chainwork.
If given only the lowest hash:
chain_work =~ (2^256 -1) / 6 / lowest_hash
StdDev =~ 5000%
P.S. My fault: we should have been calling it getnetworkhashps