I’ve seen quite a few comments about using sunrise and sunset offsets to help mitigate issues with slowdowns on the ST platform around those times of the day. However, I don’t understand how using an offset would help at all.
Sunrise/sunset times are based on zipcode. So, it’s reasonable to assume that the sunrise/sunset time is local to a specific location. As an example, sunset time today (Feb 23rd) is 6:04pm in Pittsburgh, PA, and 5:40pm in New York City, NY. (Both are in the same timezone, but Pittsburgh is several hundred miles west of NYC.)
So if I (being in Pittsburgh) was to offset my sunset time by -24 minutes, my sunset scheduled events would be clashing with folks in NYC. The point here is that, being in the Eastern Timezone, unless I were to offset by more than 1 negative hour, or more than 4 positive hours, I’d always have a time that coincides with someone else’s sunset (and sunrise) times.
So, the “offset a few minutes” thing might not matter whatsoever… and in some cases might make matters worse.
That brings up a related issue I have with the argument of ST being overloaded at sunrise/sunset times: If the sunrise/sunset times are local to each user’s zip code, then only a very small percentage of users have “sunrise” or “sunset” at any given moment. Move 30 miles to the east or west, and those times should be different. How can “sunrise” or “sunset” times cause slowdowns when “sunrise” and “sunset” is different for nearly all users?
I can, perhaps, understand that argument for an extremely high density city. There are certainly more ST users in NYC than in Pittsburgh, but the number really can’t be all that high.
Can anyone from ST comment? (Maybe I should bring this up at the dev conference call?)