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