Sunrise and Sunset still wrong

MrGibbage

Active Member
live in Norfolk, Virginia. My standard time zone is -5 GMT. My geo coords are entered and verified to be correct as per timeanddate.com
http://www.timeanddate.com/worldclock/city.html?n=420
I have the box checked to observe daylight savings in the globals. However, my sunrise and sunset times are off by one hour (ElkRP calculates the times to be one hour early). If I set the timezone in ElkRP to -4, which is my current timezone, then I get the correct sunrise and sunset times. The way it should work, is that I should enter my timezone as -5 GMT, or American Eastern Time. When Daylight Savings is observed, as it is now, then the Elk should correct the times by one hour. I shouldn't have to go in and change the time zone manually.

Did I miss something?
 
I just brought my first M1 online, so I normally wouldnt even consider posting a reply, me being such a newbie and all, but I too noticed the same thing when I went in to calculate the sunrise/sunset for my city. I placed a call to tech support at Elk today, super nice and helpful people, spoke with Brad who informed me that the calculated table does not reflect the daylight savings time, but the M1 adds the hour on internally. I am not at the site with the M1 to verify this by viewing its timed operations, so I am only repeating what I have been told, he did not offer an explanation as to why the chart does not reflect the proper time. Now you know what I know, which is not much, :) I am taking at face value, and believing in what Brad told me. Do you believe? lol

Kevin Daly
 
All sunrise/sunset times are calculated as standard time ( not daylight savings). If you have daylight savings selected, the calculation will add or subtract an hour from the standard time in the table.
 
I get it now. The table will show the "standard time" for sunrise/set. The table times are not corrected for observance of DST, but internally, the control DOES correct the times for DST. Not the best solution from a usability standpoint, but it does work. Like my C++ instructor once said, "it's not a bug--it's a feature... if you document it".

Thanks for hte help, guys.

Skip
 
I get it now. The table will show the "standard time" for sunrise/set. The table times are not corrected for observance of DST, but internally, the control DOES correct the times for DST. Not the best solution from a usability standpoint, but it does work. Like my C++ instructor once said, "it's not a bug--it's a feature... if you document it".

Thanks for hte help, guys.

Skip


I think this is the standard way of doing things. NTP sends out GMT, the individual device then adjusts for Timezone, then an adjustment is made for DST. This is how all network equipment I have seen works. I think this is because individual counties, sometimes states as a whole, determine if and how they will honor DST. There are states that have one county that honors DST and another that doesn't right next to each other all in the same timezone.
 
Good point. I guess I thought it would be useful to be able to look at the table and see the actual sunrise/set time (I'd still like to be able to show the sunrise/set time on the display somehow, but that's another thread).
 
Back
Top