Congress has passed a law to lock daylight savings time on. No systems will support this option how will hubitat do it?
They are basically fooling everyone into thinking they are ending daylight savings time. I dont know how others feel about this but I think its a scam to get people to beg for it back when it we get to the time of the year where it will be dark at 8am. Clearly its some type of trick or they would just end it.
But hubitat has no options for daylight savings time it must be automatic. I for one will not be honoring daylight savings time as locked on.
We need a option in hubitat for auto or manual time. We need the right to turn off daylight savings time.
Congress didn't.. the Senate did but the House is wavering.
No need to panic, it's still unlikely that CONGRESS will do anything. Classic politics... unanimous vote for something that "the other guys" won't pass. Zero down side.
My animals don't care what "Time" it is. When the sun comes up, they want to eat! And when it starts to get dark, they automatically know to head to the shed and/or the roost for the night.
Sun up to sunset, time is irrelevant.
So stop changing the damn clock!
(as for Hubitat or any computer... it's just code, easy to fix. We all survived Y2K, right)
Living in AZ where it is always Mountain Standard time, I offer this: For most of you, you have to put up with changing your clocks twice a year (and suffer Hubitat's inability thus far to get it right on DST change day). If you live in Chicago, it is a constant that New York is an hour ahead of you, and Los Angeles two hours behind you. And, most likely, you never even think about what time it is in Arizona.
But, living here, this time of year our clocks are the same as California, whereas we were just on Denver time all winter. Chicago is now two hours ahead of us where just ten days ago they were only an hour ahead. The whole country flips and flops around us, here an hour, there an hour.
Now that the clock changing has passed for this spring Congress really won't care enough to act on the bad idea of year-round DST, instead of year round standard time. Next DST change will be just around the mid-term elections so nothing is likely to happen then. And around and around it will go.
Think about this: a time zone is an hour wide geographically. Arizona is near the western edge of the Mountain time zone, so our sunrise and sunset are already later than Denver, as Denver is nearer the eastern edge of the time zone. This may have had something to do with why Arizona opted out of DST in the first place, because we already had quasi DST as our default.
I for one really don't care whether we have EST or EDST or whatever. Changing clocks is becoming less and less of a hassle as the vehicles now set by GPS, cell phones are set by the network. The only problem clocks are the oven, coffee maker, microwave etc and these are more of an issue with a power interruption than changing twice a year.
BUT....
What really annoys me is the belief that Congress has decided to spend time on this topic when really important items are push aside. To me it doesn't matter what your favorite topics are, I'd be surprised if it isn't more important than the time of day.
As for AZ being one of the "time rebels" we (I live in New England) had to deal with the AZ time because at that time were were doing hot weather testing in Phoenix.
We also have to deal with Mount Washington Weather observatory which stays on EST time all year else their data collection would be all screwed up.
And the Germans have a daylight savings time however they are off a week from the US because of some other bright idea our Congress had.
They didn't. It was hoodwinked through and passed by unanimous consent. The vote took 14 seconds. Most senators had no idea it happened. As others said nothing would happen until the house passed as well and president signed.
Seems odd for an automation system to not have a solid clock standard that can handle DST, leap seconds, and other offsets or adjustments. I don’t need PTP levels of accuracy. Integer seconds since Unix epoch would suffice for HA needs.
Sure it does. If you want time to not change with DST/summertime, pick one of the Etc/GMT settings. e.g. For constant EDT, you'd pick Etc/GMT+4. Note that the sign is inverted.
You’re right about POSIX. I’m thinking more along the lines of TIA and PTP. Leap seconds and local time offsets happen at the user interface level. At the back end it’s all TIA. Integer count from start of epoch. Events occur at particular integer values. Use offsets to derive UTC or local time (or any other reference clock source, for that matter).
HA probably doesn’t need the precision of TIA. But given the foreseeable persistence of leap seconds and local time variants, I am suggesting that HA would benefit from a similar model of abstraction so that offsets aren’t disruptive to time-based logic and programmed events.
Although the @bptworld animal farm is closer to how I actually live my life and run my home automation rules. Most things happen around offsets to sunrise and sunset.
I would think for any of these leap seconds to be an issue one's hub would have to run continuously for a year or more and not reboot.
For the precision your are discussing, if it is needed the Hubitat Hub is not the device you should be using. For me +/- 10 minutes is more than adequate.
Pretty sure HE uses Linux under the hood. If you set a midnight routine, it may be possible to run into a "double trigger" during leap second events, since POSIX OSs enumerate the same second twice. Wouldn't matter if you don't care about 1 second accuracy, nor how long the hub has been running.
Anything connected to the Internet normally updates automatically.
I have some clocks that receive a signal from the atomic clocks. That signal also includes whether the time is standard time or daylight time, so those clocks update automatically. However, I have some of those clocks that predate the current time change dates, so those clocks do not update automatically. Likewise, clocks on stoves, microwaves, automobiles, etc. usually have to be updated manually.
I lived in New Jersey back in the days of the Arab Oil Embargo when DST was made permanent for a couple of years. There was a reason they changed back. For those who live in southern states and for those who live on the easternmost edge of the time zone, it is not a big deal. However, if you live in a northern state and if you live towards the western edge of the time zone, DST in winter is a big problem. In Bismarck, ND on Dec. 21, sunrise is not until 8:30 am CST. That would be 9:30 CDT.
I suspect that if DST is made permanent, many businesses will compensate by changing their hours of operation. Rather than the Home Depot being open from 7:00 am - 8:00 pm, they could open from 8:00 am - 9:00 pm.
Guessing you're describing the NIST WWV/WWVH time service, which only covers the common DST case - it's not correct everywhere in the US, let alone globally. It's accurate to about 10 milliseconds, if you have a good receiver and strong signal.
The most popular IP time sync service by far, ntp, distributes POSIX time (approximately UTC), and has about the same accuracy unless you're stuck with dialup. It doesn't do anything with timezones or DST shifts, which are appropriately a local issue. It does warn about upcoming leap seconds.
It's pretty easy to set up an ntp stratum 1 server which ticks to GPS time, and is accurate in the microsecond or less range.
