Can someone explain timezones in ST to me?

General Discussion
21

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.

22

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).

23

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

24

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.

25

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.

26

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.

27

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

28

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.

29

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:

30

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
31

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
32

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.