raspberry-noaa-v2
raspberry-noaa-v2 copied to clipboard
jekhokie
Arizona timezone identified as -6 GMT during daylight savings time
Describe the bug Only a small part of Arizona uses daylight savings time. Even if the offset in the config file is supplied -7 GMT, -6 is shown and used for schedueling telemetry captures.
corrected that slight spelling error as well... its a small part of Arizona that uses daylight savings, not a Smart part
thought id check in and see if any additional info is needed or any questions posted.
Hi - im not sure what to do about this. So you think your captures are all triggering 30 min before (or is it after?) the actual pass?
A workaround might be to compensate with the PI's own clock by setting it manually offset by the correcting amount.
I checked the computer 1h 'before' LOS of the NOAA satellite pass that was susposed to happen, and I had a image of static. according to gpredict on another computer, and various websites i checked, satellite had not passed over. Is there any reason the -7GMT is not being identified?
@colinluthier @Cadair this feels like it should be a simple one... but if the time zone is set correctly the prediction should work it all out right? even with the 30 min variance from a 'normal' timezone change..
If the system clock reads right the prediction will be right. I expect that NTP takes care of all of this. It will be the annotation that is wrong.
On Sat, May 29, 2021 at 2:38 AM Dom Robinson @.***> wrote:
@colinluthier https://github.com/colinluthier @Cadair https://github.com/Cadair this feels like it should be a simple one... but if the time zone is set correctly the prediction should work it all out right? even with the 30 min variance from a 'normal' timezone change..
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/jekhokie/raspberry-noaa-v2/issues/379#issuecomment-850804628, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH3WJEEUKJ5XNLFOYCE7WC3TQCY27ANCNFSM44N3MMAQ .
I hope to find some time to do a controled test to see if the problem is simply cosmetic. getting hot in southern az. Will update with infomation as soon as i can find the time
Hello, I am in AZ too and it also identifies it as -6 UTC when -7 is provided in the config. The web ui states that a pass will occur at 21:02 but in reality it starts to record the pass at 20:02 resulting in an image full of static. If any more info is needed I will gladly provide it.
Edit: Image
trying to understand what is wrong here - is it the timezone the RPI is setting itself too, or the tz that is interpreted from the settings.yml? Or the celestrack data? Feels like something outside of the core RN2 code, but i guess we coudl work in an exceptions list to 'jump' certain timezones 'IF' they are being used... Is it all year round?
Timezones are taken care of automatically now. Follow the upgrade guide on Github. I'll reopen this issue if it still persists.
