Debugging ST's DST Fail on Time Restrictions


(Bruce) #1

For the past four days time restrictions on motion activated lights have failed here in Arizona. I believe they are probably working for most other locations. The failure is that the restrictions are acting as though we are on Mountain Daylight Time, when if fact Arizona is still on Mountain Standard Time. So for example, a light restricted not to turn on before 9:00 AM starts turning on at 8:00 AM (which is 9:00 AM MDT). In other words, ST is confused about what time zone Arizona is in with respect to time restrictions. This issue is unresolved (and reported daily to Support).

I decided to dig into what was causing this. I have an app that I use that includes the standard mode/days-of-week/time restriction code. This code can be found in a number of ST apps. For the time restriction the code uses a test on values provided by the timeToday() method of the API. Check out it’s description from the documentation:

timeToday(String timeString)
timeToday(String timeString, TimeZone timeZone)
Returns a Date object for the specified time string. The timeString argument can be either the full date and time zone string returned by “time” device preference (‘2013-06-05T22:45:30.250-0400’) or a simple time string (‘21:30’). If the timeZone argument is provided, it is used for determining the current day. If it isn’t provided or is null, then a best-guess of the time zone is made from the time input string based on the date and time zone offset. This best guess may be inaccurate for time zones other than the primary USA zones. [emphasis added]

The last sentence appears to be the reason the time restriction is failing. What sort of API includes functions that make a “best guess” at what the time is, a “best guess” that may be inaccurate for some time zones? That all by itself is ridiculous. From what I can tell all of the ST code uses the single argument version of this method.

To verify this hypothesis, I modified the code in my custom app that implements the time restriction, the code lifted from ST apps. I replaced the one argument use of timeToday with the two argument method, adding location.timeZone as the second argument. Guess what, that restriction works correctly, while ST’s standard apps fail.


(Jim Anderson) #2

Hey @bravenel, we are currently in the process of updating many of our SmartApps to pass in the timeZone, for the reasons you mentioned.

We can look at deprecating the method that doesn’t take a timeZone, since it can cause issues that you are seeing.


(Bruce) #3

Any time there is a lack of deterministic behavior in the API, that’s not good. Support did fill me in on the progress being made on this issue.


(Bruce) #4

I hope you realize that there is a lot of ST published code in the SmartApps Templates that uses the single argument version of timeToday() in getTimeOk(). That should all get cleaned up so others don’t step in it.


(Brian Steere) #5

Why doesn’t it use the timezone based on your location?


(Bruce) #6

It should, but doesn’t; it’s a bug.