Can someone explain timezones in ST to me?

Just following up on the posts above,

I’m based in the UK I’ve been having trouble with timings not firing. when I looked at the IDE my time zone was not registered and all times were in a US time-zone correct times but represented in the wrong time-zone, also the was no record of sunrise or sunset times.

So a quick drag of my location away, save and then back again on the mobile app and I now find my time zone is correct (if you assume Europe/London is GMT) and my sunrise sunset is now showing a time.

This looks like one of those nice quick fixes to a series of problems I’ve been having.

Hope that helps others

Hello I am new to ST. I am having the very same problem! My hub is in the uk, and I am working in Switzerland. Switzerland is 1 hour ahead of the U.K.

I have programmed the ST hub to my girlfriends living schedule, as she is living in the house in the UK!

Me, being here in Switzerland, has thrown all of the programming out by 1 hour!

For example : motion sensors set to enable at 8pm shown on my APP on my phone, will actually enable at 7pm UK time!

Is there a way to change this? I would like ST to actually use the hub as a reference ONLY! for the time, and not the app on my phone.

I know I could actually change my iPhone time back to the uk time whilst abroad, but I don’t really want to do this!

My app location pin is set correctly to my street in the UK

any ideas how to fix this?

I have the same issue when making edits to the system for my wife. When I am traveling away in a different time zone the fix will reference the app time not the hub time.

So far the fix j have found is either changing my phones time, or making the offset adjustment in my head.

And then when I return home I go through and re check the times and re initiate.

I hope this is something fixed over time.

My confusion was also arising during edits for my girlfriend back home. I have just played around with it again!

I found it was easier to change the time on my phone back to UK time, so that I could programme it like I was actually in the uk, then once I was finished, I changed the time back to Switzerland time!

Saves on making offset adjustments!

The times shown on the app will automatically adjust to the time zone set on the phone.

For example:- I changed the phone time to UK. Programmed a light turn on at 8PM. Changed the phone time zone back to Swiss time and it shows 9pm in the programming, which will fire the action 8pm UK time.

Swiss is +1hr over UK time.

It would be nice though, if when programming a time, it was the applied to the same timezone where the hub is located

I will check this evening how it handles the sunset command. If it uses the hubs data for sunset, or sunset time in Switzerland, where I am based at the moment!

I can confirm that it does use the timezone and sunset/sunrise local to the hub.

The ST SmartApp times just adjust to reflect the timezone in which you’re currently in!

It only really becomes confusing if you make adjustments whilst on a different time zone from where the hub is based.

Whilst away from home, if I wanted to program a light to turn on at 8pm UK time, when I am in Switzerland, which is 1 hour ahead, I would have to program it to turn on at 9pm whilst my phone is on the Swiss timezone!!

As mentioned on my previous post. Setting the phone temporary to the time zone in which the hub is based, stops the confusion!

1 Like

I cab confirm that it does NOT work. I am visiting my son in a Timezone 3 hours away. When I changed a rule to switch off my fish tank lights at home, it used my iPhone time and not the hub time. So the rule was wrong. The initial rule showed the hub time correctly. Also found its beter to manually set my phone time to hub time. But that’s a pain and I often check my devices to see if things are right home. Please fix this.

Seems to me this should be embedded in the firmware for time zone with the ability to sync to time.nist.gov or other synchronize time setting over the internet. You would think someone from smartthings would resolve this by now.

Hi,
I’m getting some problems setting up my location with the right timezone.

My problem is a little bit weird, as if I setup my location to 1km of my house it will display the right timezone (Europe/Lisbon), but if I place it in my house it will dispay a different one (Atlantic/Azores).
This timezone should only be applied to portuguese islands in the middle of the atlantic, and not to Portugal.

Is there a way to manually override the assigned timezone? I would like to have my house properly setup so that I can use the geofence and the phone as a presense sensor.

This time zone shift remains a major problem (Oct 2017), all rules should fire based on hub location time. I experienced this issue again this week.

If I modify one Smart Lighting rule while traveling away from the hub time zone, MANY (All?) of my Smart Lighting rule firing times offset by the time difference between zones. Stays that way even when I return to the home time zone.

The “work around” is not practical – to manually set the phone’s time back to the hub location when traveling, and then back. Yes, 98% of the time users may stay in their hub’s time zone, but people do travel (vacation, work, whatever).

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.

The symptom is easily replicable 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. Bam! Pretty much every rule fires 3 hours too early. Symptom also experienced when I traveled to Netherlands (UTC +2 CEST).

SmartApps run in the ST Cloud and the ST Cloud uses the hub’s timezone to schedule and execute events. I think what you’re facing may an issue with the ST scheduler running off base by a few hours which was patch up recently. You will need to reinitialize your apps to get the time corrected:

New Incident Status: Monitoring
We have resolved the issue causing scheduled SmartApps to execute early, but many SmartApps may still be scheduled for the incorrect time. After running once, the schedule will be set for the correct time moving forward.

However, you can manually force the schedule to update to the correct time by going to the ‘Automation’ page in the SmartThings app, navigating to ‘SmartApps’, tapping on the SmartApp you need to re-schedule, and simply hitting ‘Done’ on the upper right. If it’s a Routine, you can do the same by going to the ‘Automation’ page and tapping the gear icon, then tapping ‘Done’ on the upper right.
Oct 14, 20:08 EDT

No.

The problem is that when you create a rule, the mobile app creates the rule using the mobile device’s time zone, not the hub’s time zone.

For example, say you have a hub on eastern time, and you want to turn on a light at 6pm eastern time. If your mobile device is on Pacific time, and you create a rule to turn on a light at 6pm, it gets created on the hub as turning the light on at 9pm.

So what you really need to do is create the rule to fire at 3pm. That becomes 6pm eastern time on the hub.

But if you look at an activity log, the mobile app doesn’t translate time zones. It just shows the log contents, with the timestamp of the hub.

Back to my example, creating the rule, the mobile app converted time zones. Displaying the activity log, it does not.

My biggest ask is that Smarthings just show the timezone when they display times. Since the mobile app sometimes converts timezones, and sometimes not, it’s very confusing.

Are you sure? What SmartApp are you using?

AFAIK, the SmartApp only captures the time from the user (not the zone), the SmartApp when it schedules the activity should be using the timezone from the hub (since it’s running in the cloud) to schedule it. I don’t think there’s even any way for the SmartApp to know what timezone the user’s mobile phone is in.

I could be wrong, or it could have changed. I’ve not tried creating new timed rules recently. But I used to do this a lot and it was a serious problem.

With regard to the SmartApp running on a mobile device knowing the device’s local timezone, I thought it was just a trivial call to getTimeZone() on Android in a Java app. But I don’t build a lot of mobile apps these days. Not sure why it would be hard though.

SmartApps run in the cloud and not in the mobile phone. That api used to be provided by ST but now has been deprecated if I remember correctly or it returns the hub timezone. I know this was an issue quite some time ago but I believe it’s been fixed by ST

SmartApps run in the cloud and not in the mobile phone.

Completely irrelevant. You’re completely misunderstanding me. I’m talking about the SmartThings Android app. Not the Groovy apps that run in the ST Cloud. getTimeZone() is an Android API call. This whole discussion has nothing to do with apps that run in the ST cloud. It’s all about the UI in the mobile app running on your mobile device, and how it translates (or doesn’t translate) times when displaying them in the Android (or iOS) app on your mobile device.

So here we are: November 2018, over a year later since the last post and the timezone offset is still an issue. I travel between the US (PST) and Europe (CET) on average every month with a time-diff of 8-9 hours (depending on daylight savings time in europe).

It is certain without a doubt, the schedules set up in the smartlighting smartapp is following the timezone of my phone and NOT the hub at home. Like a good little customer I’ve reported it to Samsung Support, so we’ll have to see what they’ve got to say.

In the meantime if someone in another thread has found a solution or written an alternative lighting smartapp to replace the stock app, I’m all ears as wifey is going nuts over the altered schedules every time I’m out of town, i.e. the WAF of Smarthings is dropping like a rock… :grimacing:

Looking at the docs it’s possible to use either the phone timezone or the hub timezone. It’s upto the developer of the app. We tend to always use the hub timezone for exactly the reason you mentioned.

1 Like

I’m having similar issues in UK using SHM, which I have automated to come on at a set time. When I was recently in Paris (GMT+1), the SHM was arming an hour early - meaning the wife was setting the alarm off back at the house in the UK. Seems a major flaw…

1 Like

And this is still an issue today. :joy:

It shouldn’t be left to 3rd party developers. It should be the same for all devices and for simplicity it should use the hubs time zone not the apps. It’s a joke.