There’s a bug in the SmartLighting app that’s pretty easy to re-create: I recently took a trip (from California) to The Netherlands. After arriving in The Netherlands, I decided to put some of my house lights on timers. So I went to Smartlighting set up a timer to have some lights come on at 8pm …

The time should always be in UTC. This way your automations shift an hour with daylight savings. CoRE and webCoRE both store date/time in UTC for this exact reason. I guess SL does the same, the problem was your phone switching timezones.

Yeah, envision this: you live on the west coast. Hub is on the west coast too, currently 7 hours behind UTC. You go to New York, phone changes timezone, now only 4 hours behind UTC. You make a rule for 7pm - the ST app translates that to 11PM UTC, based on the phone’s timezone. But 11PM UTC really m…

Different platforms implement this differently. As of iOS 10, HomeKit bases all rules on the local hub’s time zone unless specifically coded otherwise. https://developer.apple.com/documentation/homekit/hmtimertrigger/1616268-timezone?preferredLanguage=occ

I don’t see any logic that leads to the current behavior - just baffling. I wonder how it deals with sunrise/set times? If I made a rule to turn on lights at sunset and off a sunrise would it use the location of my phone to determine that rule, then track it? Time is such a fundamental thing for …

Pretty sure sunrise and sunset aren’t set based on the phone. Your account uses your hub’s location for those and the time gets updated down to the hub every day. It’s hour based time triggers in routines and smart lighting and smart home monitor that convert from the phone’s time to UTC before s…

The “work around” is not practical – to manually set the phone’s time back to the hub location when traveling, and then back. Yes, maybe 2 sigma of the time users may stay in their hub’s time zone (95%), but people do travel (vacation, work, whatever) so the app and hub should be bulletproof. This …

Hmm, does not sound like it was implemented optimally, and here is why. For recording something that is a full date plus time, either in the past or the future, a common practice is to record this in the database as UTC, then for display purposes can show converted to local time zone. But for reco…

[image] NokiaFan: The “work around” is not practical – to manually set the phone’s time back to the hub location when traveling, and then back. Yes, maybe 2 sigma of the time users may stay in their hub’s time zone (95%), but people do travel (vacation, work, whatever) so the app and hub should …

FAQ Timezone bug in SmartLighting? (SmartLighting used phone's timezone, not hub's)

Wiki FAQ

JDRoberts June 17, 2017, 11:49pm 3

I’m pretty sure that automations have always been based on the time in the mobile app when you create them. I don’t think that’s anything new. People have been reporting on the “I was on vacation and created a new routine…” Issue for as long as I can remember.

Topic		Replies	Views
Can someone explain timezones in ST to me? General Discussion	31	13189	November 8, 2021
SmartThings schedule follow Mobile TimeZone General Discussion	11	2224	December 11, 2016
SmartLighting lights come on randomly SmartApps & Automations smartapp , smartlighting , hubv2 , z-wave	6	1473	November 24, 2017
Smart Lighting schedule not updated to reflect Standard Time and not correct for my location SmartApps & Automations	8	760	November 26, 2018
MAJOR TIME ISSUE uncovered? General Discussion	2	1198	December 19, 2015

FAQ Timezone bug in SmartLighting? (SmartLighting used phone's timezone, not hub's)

Related topics