Storagenode dashboard: storage graph timezone issue
The storage graph for me is always ~10% lower on the first day and ~10% higher on the last day.

I think this is because the month time range (link below) uses local time but everywhere else we use UTC. So my month starts and ends at 2h00 instead of 0h00 because I am in UTC+2.
https://github.com/storj/storj/blob/07beef378d5ceec57bc1de546edad4981264c982/private/date/utils.go#L10
Probably the easiest fix would be to change it so this range uses UTC timezone. Check if this negatively affects any other uses of this code.
I actually think we should try to respect the users timezone in the dashboard but at this point this may be more difficult and doesn't add too much value. It would also lead to different accounting than on the satellite.
I think this is because the month time range (link below) uses local time but everywhere else we use UTC. So my month starts and ends at 2h00 instead of 0h00 because I am in UTC+2.
I'm not sure if that's exactly the issue because all time passed to the function uses UTC timezone: https://github.com/storj/storj/blob/07beef378d5ceec57bc1de546edad4981264c982/storagenode/console/service.go#L375 https://github.com/storj/storj/blob/07beef378d5ceec57bc1de546edad4981264c982/storagenode/console/service.go#L270
Even references on the multinode side: https://github.com/storj/storj/blob/07beef378d5ceec57bc1de546edad4981264c982/storagenode/multinode/bandwidth.go#L67 https://github.com/storj/storj/blob/07beef378d5ceec57bc1de546edad4981264c982/storagenode/multinode/bandwidth.go#L85
For the lag at the beginning, I'm expecting that tally might have started sometime within the last day of the previous month to the first day of the current month. I checked Redash and it looks like tally had the least run time at the beginning of the month on some of the satellites:
This is for AP1 satellite:

Same for EU1:

We probably need to wait for another month to see how this behaves. I can't say much about the ~10% bump on the last day.
I will ask the SNO community if anyone has a similar issue.
This issue has been mentioned on Storj Community Forum (official). There might be relevant details there:
https://forum.storj.io/t/can-any-us-operator-check-their-storage-graph-for-me/19715/1
The ~10% bump on the last day is reasonably expected IMO since we're only estimating the value obtained as at the time the node contacted the satellite i.e. 24*[(at_rest_total in bytes*hour)/(total_hours)]. At the end of the day, the value might be relatively less than estimated.

We can safely close this issue since it was fixed after we switched to using bytes unit.
cc: @shaupt131