@ady624 - Just checking to see if you had any insight on this by chance? I checked to see if the latest updated fixed the yearly option but still showing 2018 for first scheduled if i pick any future date in 2017.
Thanks!
[BUG?] Using timer statement every 1 year always schedule next run in 2018 even if selected date is not passed in 2017
ady624
#24
This worked (timer every day)
This worked too (timer every month)
This didn’t work (every year) - will look into it
Jrrobertson3
#25
Thanks for the example @Kebel871!
@ady624 - Not a problem. It’s not like you dont have anything else going on :cough: mobile app :cough: 
talz13
#26
I’m having the same issue… tried scheduling for every year, on last day of December, and scheduling for every 1 months on the last day, but only in December, is still giving me a next scheduled date of 12/31/2018:
Kebel871
#27
Yeah it’s still a pending issue. @Robin @ipaterson do you guys think it should submit it as an issue in github? Would it be helpful?
Robin
#28
@ady624 is unable to work on webCoRE right now for various private reasons which I won’t go into… he’s aware of the bug though and I’m sure it’ll get fixed eventually.
Wouldn’t hurt to post the issue on GitHub though.
Robin
#29
For now you could use an expression instead:
datetime(‘12/31/’$year’ 23:59:00’)
The expression goes in a time/date trigger (condition dialogue) rather than a timer.
ipaterson
#30
@ady624, it seems this was introduced back in June with a change that addressed a problem where “sometimes ST runs timers early, so we need to make sure we’re at least in the near future”. The effect of that change in this case is that the nextSchedule is one second before the value of rightNow, so when the piston is saved it acts as if the target date has already passed.
I could look up the context of that change in the forums but this is likely something that would be too risky for me to publish a fix without a better understanding of how all the scheduling works. Anyone looking for a patch to test can make the following change around line 1857 of webCoRE Piston then re-save your affected pistons:
change
int month = (intervalUnit == 'n' ? date.month : omy) + (priorActivity ? interval : ((nextSchedule < rightNow) ? 1 : 0)) * (intervalUnit == 'n' ? 1 : 12)
to (note the change nextSchedule + 1)
int month = (intervalUnit == 'n' ? date.month : omy) + (priorActivity ? interval : ((nextSchedule + 1 < rightNow) ? 1 : 0)) * (intervalUnit == 'n' ? 1 : 12)
That is not likely to be a comprehensive fix, I was only looking at the every 3rd day of November case. May give this more attention when I have time but for now please consider @Robin’s workaround.
c1arkbar
#31
If I recall correctly basically what was happening is when someone had some code like
time happens daily at 9:03:00pm
Then SmartThings looks at it and is like ok 9:02:59 is close enough so run it. But the pistons would fail to execute because 9:02:59 ≠ 9:03:00
Kebel871
#32
@ipaterson looks like you’ve been on fire squashing some bugs lately. Do you have this one on your list?
ipaterson
#33
Scheduling bugs are tricky, I have a few submitted for @ady624’s review. I’m not familiar enough with the quirks to push those out myself. Has anyone tried the tweak posted above? I’ll submit a slightly different fix that looks like it might better resolve similar issues caused by the rightNow variable getting advanced by 1 ms when the piston is changed.
