How to Fix Smart Home Devices an Hour Off After DST
Device clocks or schedules are one hour off after the DST change.
Last updated

Start with the part that is actually an hour off. A thermostat display showing 9:00 when every phone in the house says 10:00 is a different failure from a porch light routine that fires at 9:00 while the app clock looks correct. The first points toward a visible time source problem. The second points toward the schedule engine, home location, hub, or cloud account using stale local-time data.
The useful fix after a daylight saving time clock change is this: do not hunt for a manual clock setting first. Most smart-home devices do not give you a real clock to set. They inherit time from somewhere else — the phone, the account address, the home location, the hub, the cloud service, the network, or the host system running the automation platform. The fix is to make the right source refresh.

First split: bad display time, or bad schedules?
| What you see | Most likely stale source | What to refresh first |
|---|---|---|
| Device screen, camera timestamp, thermostat clock, or smart display clock is one hour off | Device time source, phone-derived time, hub time, or network time | Phone time settings, device app time sync, hub restart or time-zone setting |
| Clock looks right, but routines, schedules, scenes, or automations fire one hour early or late | Schedule engine, home address, app location, cloud account, or automation platform time zone | Home location/address, account time zone, automation platform time zone, then re-save schedules |
| Only one brand is wrong | That brand’s app, cloud account, hub, or device cache | Use the brand-specific resync path below |
| Everything in the home is wrong, including devices from different brands | Phone, router/location service, hub platform, DNS/VPN side effect, or blocked network time | Fix the shared source before changing individual routines |
| The device was correct after the clock change, then drifted or reverted later | Delayed cloud/app resync or hub time refresh that did not stick | Force a second sync, then check non-DST network causes |
If the display is wrong, do not rewrite all your automations yet. Fix the device’s time source and then watch whether the existing schedules recover. If the display is right but routines are shifted, do not waste time looking for a device clock. The clock you can see is not the clock making the scheduling decision.
The three time sources that usually need a kick

A one-hour offset after daylight saving time usually comes from one of three places.
- The home, account, or device still has a stale location or time-zone cache. This is common when the app knows your address but the device or cloud service has not refreshed the derived time zone.
- The device inherits time from the phone or app session. If the phone has the wrong time zone, a disabled automatic time setting, a travel/VPN side effect, or stale app permissions, the device may follow bad data.
- A hub, bridge, server, or device never re-triggered time sync after the clock change. Schedules can keep using the old offset until that component restarts, reconnects, or reloads its time-zone setting.
The right fix is usually boring: confirm the source, change or re-save the location/time-zone field, close and reopen the app, then restart only the device or hub that consumes that source. A factory reset is rarely the clean first move because it can remove working integrations while leaving the same account-side location problem waiting for the device when it comes back.
Nest and Google Home: refresh the home address before blaming the thermostat
For Nest thermostats, displays, cameras, and Google Home routines, treat the home address as a real time source. A June 2026 Google Home and Nest Community case about a Nest device showing the incorrect time was resolved by correcting or refreshing the home address/location sync, not by setting a hidden thermostat clock. [1]
In the Google Home app, check the home itself first: open Google Home, select the affected home, go to Settings, then look for the home information, address, or location field. Confirm the address is not merely present, but correct enough for the app to derive the right local time zone. If it already looks right, edit it slightly, save, then correct it and save again. That re-save matters because it forces the account to reprocess the home location instead of just showing you the old cached value.
If the affected device still appears in the older Nest app, also check the home information there. Use the Nest app’s home settings or home info area to confirm the home address. After saving, close both apps fully, reopen Google Home, and give the device a few minutes online. For a thermostat that still displays the wrong time, restart the thermostat after the address has been refreshed. Restarting before the address sync is fixed only makes it ask for the same bad answer again.
If Google routines are an hour off
Open the routine, check the scheduled time, and save it again after the home address refresh. If the routine uses sunrise or sunset, confirm the home location first; those triggers depend on location, not just the clock on a display. Do not delete a working routine until you have tried a simple open-save cycle after the home’s location data has been refreshed.
Alexa and Echo: check both device location and routine timing
With Alexa, separate Echo display time from Alexa routine time. If an Echo Show or Echo Dot clock is wrong, open the Alexa app, go to Devices, choose Echo & Alexa, select the device, then open its settings. Check the device location and any time-zone field the app exposes for that device. Save the location again even if it already looks right.
If only routines are shifted, open More > Routines. Open the affected routine, inspect the schedule trigger, and save it again. For location-based or sunrise/sunset routines, check the device or household location before changing the trigger. If several Echo devices disagree, fix the one used as the location reference or the one that owns the routine, then power-cycle the affected Echo only after the app-side setting is saved.
Wyze: sync device time, then re-save rules
Wyze cameras and plugs often make the split visible: camera timestamps can be wrong while rules look fine, or rules can be late while the live view time looks normal. For a camera timestamp problem, open the Wyze app, select the camera, open the device settings, and look under advanced or device information settings for a time sync option. Use that before changing schedules.
For rules that fire an hour off, go to the Wyze rules area, open the affected schedule, check the trigger time, and save it again. If the rule uses sunset or sunrise, confirm the home/location setting in the Wyze account or app first. When a Wyze hub or bridge is involved, restart the hub after confirming the app location, then test one simple scheduled rule before rewriting the rest.
Kasa and Tapo: update location/time zone at the home or device level
For TP-Link Kasa and Tapo plugs, bulbs, switches, and cameras, schedules are usually more important than the visible clock because many devices do not show one. Open the Kasa or Tapo app and check the home, location, or time-zone setting in the app settings or device settings area. If the app lets you set location at the device level, check the specific plug or switch that owns the schedule.
After saving the location or time-zone field, open the schedule or timer on the affected device. Re-save the schedule. For sunrise and sunset automations, check the location before testing, because changing the clock time alone will not fix a bad solar trigger. If the plug or switch still fires at the old offset, power-cycle that device after the app location has been saved.
Ring: device address comes before motion schedule edits
Ring devices tie a lot of behavior to the address attached to the location. If a camera timestamp, mode schedule, motion schedule, or lighting schedule looks one hour off, open the Ring app and check the location or address for the site first. Then open the affected device’s settings and look for general settings, device location, or address-related fields.
Once the address is correct, re-open the motion schedule, light schedule, or mode schedule and save it again. For a single camera with wrong timestamps, reconnecting or rebooting that device can help after the address refresh. For multiple Ring devices at the same address, do not restart every camera first; fix the shared Ring location, then test one schedule.
Home Assistant: fix the platform time zone before editing automations
Home Assistant is where a DST problem can look like a device problem while actually living in the server, container, operating system, or Home Assistant time-zone setting. Start in Home Assistant itself: open Settings > System and check the general time-zone setting. Confirm it matches the home, not the server’s physical host, a cloud region, or an old configuration value.
Then check the host underneath it. A Raspberry Pi, virtual machine, NAS, Docker host, or supervised install can have its own time and time-zone configuration. If Home Assistant shows the wrong local time, fix the host and Home Assistant time zone before touching automations. If the dashboard clock is right but automations fire late, open one affected automation, inspect its time trigger, save it, and reload automations or restart Home Assistant if needed.
For Zigbee, Z-Wave, Matter, or vendor integrations inside Home Assistant, do not assume every end device has a DST bug. Many of them are simply responding to Home Assistant’s scheduler. Fix the central platform time first, then test a single automation with a near-future trigger.
Aqara: check the home, hub, and any bridge into another ecosystem
With Aqara, the hub matters. Open the Aqara app, check the home or home-management settings, and confirm the home location or time-zone field if the app exposes one. Then check the affected hub’s settings. If scenes or automations are an hour off, save the home or hub time-related setting again before editing each scene.
If the same Aqara device is also exposed to Apple Home, Google Home, Alexa, or Home Assistant, find out which platform owns the schedule. A sensor can report correctly in Aqara while a schedule created in another app fires late. Fix the scheduler, not the sensor. After the correct home or hub setting is saved, restart the Aqara hub only if the wrong offset persists.
When it only looks like a daylight saving time problem
A clean one-hour offset right after a clock change usually points to DST, but not always. If the problem survives a phone check, location refresh, app sync, and hub restart, stop treating it like a simple seasonal clock issue.
Router or ISP geolocation
Some services infer location from the network path. If a new router, ISP change, cellular failover, travel router, or mesh setting entered the picture around the same time as the clock change, the service may think the home is somewhere else. Check whether apps report the wrong city, region, or time zone. If they do, fix the account address first, then restart the router or affected hub so the service has a reason to ask again.
VPN, private relay, or custom DNS
A phone VPN can poison setup or resync steps because the app may refresh location while the phone appears to be elsewhere. Disable the VPN or private relay temporarily, reopen the smart-home app, and re-save the home address or time-zone field. If custom DNS or filtering is installed at the router, test from a normal network path before assuming the device firmware is wrong.
NTP and port 123
Network Time Protocol traffic commonly uses UDP port 123. If a firewall rule, parental-control profile, VLAN policy, or security appliance blocks time sync, a hub or device can fail to refresh its clock correctly. This is end-of-ladder troubleshooting, not the first tap. Check it after the easy source refreshes fail, especially if a local hub, Home Assistant host, NAS, or camera system shows wrong time while cloud-only devices behave.
Morning-after recovery ladder
- Check the phone used for setup. Turn on automatic date, time, and time zone. Disable VPN or private relay while fixing the smart-home app.
- Decide whether the bad symptom is the visible clock or the schedule engine. Do not edit every routine until you know which one failed.
- Refresh the home address, home location, or time-zone field in the app that owns the device or schedule. If it looks correct, re-save it anyway.
- Close and reopen the app. If there is a hub, bridge, thermostat, or display that consumes the refreshed setting, restart that component after the app-side save.
- Open one affected schedule or routine, verify its trigger, and save it. Test one near-future schedule before rewriting the entire home.
- If the one-hour offset remains across multiple ecosystems, check router geolocation, VPN/custom DNS behavior, and whether local hubs or servers can reach network time.
- If only one device remains wrong after the shared source is fixed, restart or re-pair that device last. Save factory reset for the point where the account, location, hub, and network time sources have already been cleared.
At that point the outcome is clear. If the display corrected and schedules now fire on time, the issue was a stale time source. If the display is right but schedules remain shifted, the scheduler still has old location or time-zone data. If several unrelated platforms are still one hour off after their locations are refreshed, it is no longer just a DST fix; look at the network path and the system that supplies time to the home.
References
- Nest showing the incorrect time, Google Home & Nest Community, June 2026.
Corroborating context
For protocol background on why this failure happens, see Compatibility & Protocols.
Not currently linked to a known regression. Background on the underlying protocol lives in Compatibility & Protocols.
