|
|
One thing that kind of surprises me about this entire thread is that
only sunset is considered!
Seems the OP wanted to use it for a Home Automation solution, and it
seems to me that sunrise may also be needed! (The OP might not see it
now, but it does come in handy!)
Something as simple as "turn porch light on at sunset, off at sunrise".
Therefore the table based solutions may actually require double the
table space being discussed...
One other thing I didn't see (may have missed it) is if the platform/OS
"knows" about DST setting, and sets it's internal clock correctly
(window/linux come to mind). If that's the case, the table will need to
vary each year, as the change doesn't occur on a specific J date, but on
one of 7 or so.
Again, for a HA solution, I'd assume this is the case - again, something
as simple as "turn on coffee maker at 6am" would be tied to "clock time"
and should know about DST.
Of course, if the OP was in AZ, DST wouldn't be an issue! (now if only
the rest of the US would take this "logical" approach! :) )
For HA, I would go with an math based solution vs table. You really
only need three things (4 if you do DST) - Lat, long, Jdate, DST mode,
and the resulting compiled code could be smaller than the table, and
more accurate!
|
|