I have a job via schedule() that runs every day at 9am. Today it ran at 8am. Does the schedule() not account for DST changes?
That would suggest not. What if you restarted the hub? Or at least did something that re-setup the schedule?
Before you so that, what does it show as the next run time?
next run is 8am. Here's why. I have a time variable:
Clearly 9am. I pass that into timeToday with a timezone:
def timeVal = timeToday(time, location.timeZone)The reason I do this is because I need to parse the hours/minutes separately to build a cron string.
The output of that method is 8:00 AM. What I suspect is it's because the time variable has EDT encoded in it (though not displayed anywhere) and now the timezone is EST. Honestly not sure what to do here. I'd have expected time variables (which are always local time) to auto adjust?
By time variable do you mean a hub variable or something similar?
No.
input "startTime", "time", title: "Start time", required: true
Ok, only thing I can suggest, apart from following up on how the time data type is intended to work, would be to store it as text and parse it
Yeah. That just seems like a hack though which I'd prefer to avoid if possible. DST, though I agree is an archaic concept, and a terrible pain to program for, affects over 1 billion people. Computer platforms should be able to "just work" with it.
I'm 99% sure this is a platform issue. When I rerun my stuff today to create a new call to schedule() all is well. It's just when I am scheduling the next run (for today) yesterday (when DST was still in effect) that it broke. Unfortunately, HE doesn't seem to give me any good way to mess with DST for testing so I really won't even know if it's fixed until March when DST begins again 
Only other thing I can suggest is to convert it on the way in into some utc representation and convert that on the way back out, rescheduling after each run
That's kind of what I do, sorta. This is what I suspect happened though, and why that can't work:
11pm EDT on 11/6 I call timeToday("9:00", location.timeZone) -- at this point location.timeZone == EDT and so it converts the output to an EDT time value so, 9:00EDT which is 8:00AM EST. At 2:00AM EDT we switch over to EST. So now my schedule is set to run at 8:00AM EST.
The problem is tomorrow's timezone is a different timezone than today's when I call timeToday(). What I need is a way to find out TOMORROW's timezone value which, in this case would be EST. I think I'll have to do this myself since HE only provides a timeToday method, and really I need a timeTomorrow essentially. Think I have a path forward, thanks for the help!
1 Like
The platform and its scheduler does adjust for DST ending. Please show the scheduled job (its cron string).
Note that "time" input uses the browser's time picker for 12-hour time, and inputs separate hour and minutes fields manually for 24-hour time. If the browser time zone (or DST state) differs from the hub time zone (or DST state), there can be an discrepancy in the time displayed.
Let me explain whathappened:
At 12AM on 11/7 (DST still in effect) I called schedule("00 0 09 ? 9,10,11 *")
Then at 2AM on 11/7, DST ended, EST went into effect, and my schedule ran at 8am instead of 9am
I'd love to test further and reproduce this, but I can't seem to find anyway to get my hub to think DST is still in effect. I tried updating my computer's date to 11/6 and clicking Update Time From Browser Time but that didn't seem to work. I'm happy to do some more digging to help figure this out but I'd need some way to trick my hub into thinking DST is still in effect.
Might have to change the NTP setting or block the access to the NTP, so that it doesn’t recheck
Hmm, where is the NTP setting? I don't think I've seen that
Haven’t played with this yet (on my list) but:
Check out this post from a while back
1 Like
I wonder if I set it to an invalid ip if it will let me disable it.
