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

Wiki FAQ
1

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 and turn off at 11pm. Easy.

Except, I come home to find out that the lights were coming on at 8pm and and turning of at 11pm CET (Central European Time) and not the time zone where my Hub (and house) are (Pacific).

This is a bug, no? The times used by the SmartLighting app should be the in the time of the Hub/Location in which the app is installed. Instead, it was using the local time where I was with my phone when I created the SmartLighting instance

2

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.

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. :disappointed_relieved:

1 Like
4

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 means 4PM for the hub, as it still is 7 hours behind UTC. Now, had the ST app use the hub timezone (regardless of the timezone of the phone), the story would match. Not saying the app is doing something wrong, it is normal for this to happen. The solution would be to have the app relate to the hub’s timezone, but it does not. The moral of the story: when going on vacation consider acting like being on vacation and leave your hub alone ;)))

1 Like
5

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

6

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 an automation company - how can they have messed this up? Although, I’ve been here since 2013, so I guess I know the answer…

1 Like
7

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 sending the rule to the cloud to be stored. Which is what causes the problem.

You could avoid the problem by setting your phone to your hub’s time zone before opening the SmartThings app and doing anything there, then setting it back again, but obviously that’s annoying.

(Also, I’ve made this into an FAQ, just so we can refer people here the next time the question comes up. Since it doesn’t look like SmartThings has any plans to change the way it works.)

2 Likes
8

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 time zone shift remains a major problem (Oct 2017), all rules should fire based on hub location time. If I modify one Smart Lighting rule while traveling away from the hub time zone, then MANY (All?) of my Smart Lighting rule firing times get offset by the time difference between zones. Stays that way even when I return to the home time zone.
Now I have to edit each rule manually back in the home time zone, and in some cases I have to delete then re-enter them to make them work properly.

The symptom is easily replicable. Why is this not a primary functionality? For instance:
Hub remains in USA PST (UTC +8) time zone. User phone travels to USA EST (UTC +5), phone time auto-updates to local time zone. Use phone app to change a Smart Lighting rule, most of which are like “Sunrise-30 minutes” or “Sunset+55 minutes.” Bam! Pretty much every rule then fires wrong by 3 hours. Symptom also experienced when I traveled to Netherlands (UTC +2 CEST), Hawaii, etc.

1 Like
9

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 recording schedules or things that have only the time component, then just the time component can be stored, no time zone, no date.

For example, for some software we have that has employee schedules, there are start and end times.

So if the schedule starts at 8:00 am. 8:00 am is stored in the database, just time, no time zone and no date, then when each day starts, the actual start of the schedule is recorded depending on local time zone and daylight savings in effect, and that complete date+ time is converted to UTC. So each day actual date/time start of schedule is computed.

When a schedule is entered by the supervisor, if 8:00 am is entered, 8:00 am is recorded into the system regardless of where the person is entering the 8:00am.

Whether the person is in the UK or in NY, 8:00 is recorded because the schedule is supposed to start at 8:00 am local time.

This is different then recording a schedule for a meeting. The meeting is a definite date + time and time zone,

In this case it can be confusing what time you entered as compared to other people you are inviting that are not in your time zone.

10

Yep. As I mentioned before, it’s baffling to me why you wouldn’t want a timed event that’s tied to a physical hub not occur in the timezone the hub is located in. It’s not like the z-wave/zigbee/wifi switch can be in a different timezone than the hub anyway.

If I call my office from across the country and tell them to set up a meeting for 9am next tue when when I’m back - should I expect my secretary to schedule the meeting at 9am where I happen to be calling from or for 9am where I work, my secretary works, and where the meeting physically will be located? :exploding_head:

1 Like