Pistons have stopped working! [daylight savings time issues]

[Royski]

Working here again. Thanks @ady624

[wjstefanelli]

Just upgraded to 0fd without issue, and things are working. Thanks Ady!

[ady624]

Any errors in the IDe logs?

[smartie]

Working now…Somehow the piston didn’t get updated…I wish I had the Github integration working
Thanks for getting it back working, Adrian!

[GTH]

All working here too, and schedules times are correct. Still showing the banner “A newer UI version (v0.2.0fd.20171105) is available, please hard reload this web page to get the newest version.”

[Kebel871]

Nope, IDE live logging shows no error when pausing/resuming/editing.

Can this screenshot help?

P.S.: datetime $nextscheduledtime still shows “invalid date”

[Snuffy2]

I’m seeing the same thing on one of my pistons as well. It’s set to run at 4 AM every morning but says next run time is 3 AM at the top. The rest of my pistons seem to be fine so far. Eastern time zone. Tried pausing, restarting. Changed time by a minute, no change.

[Eric182]

Same here. Piston is set up for 5:30 am, but next scheduled run time is 4:30am

I’ve tried editing, pausing, all the usual tricks to no avail. On the latest version.

All other pistons are fine. Some I had to pause/resume to fix the times, but this one is being stubborn

[Kebel871]

It seems that pistons firing between 2/3-6AM are the ones having problem.

Edit : can confirm that anything after 6AM is fine, between 2/3 and 6AM bugged. That is for EST (GMT -5 , I guess it’s somehow related)

[Jwwhite]

I’ve got the same issue. Updated all apps. Paused and restarted. Still showing things 1 hour too early.

I’ve been on the road all day and am just now being able to look at things. Kinda concerned that I had to update the apps to get anything to work. being gone I couldn’t follow the posts and didn’t know nothing was working.

[ady624]

Will check when I get home

[Kebel871]

No worry mate, I’m reporting to help debug. As far as I’m concerned, I’ve paused them for the night to prevent my wife from killing me at 4:20 tomorrow morning (aka lights turning on gradually 1h too soon = extra grumpy wife lol)

[Jwwhite]

I paused also.

[ipaterson]

No luck here trying to figure it out. Restore 7e9m3 for a simple timer set for 3:30am that schedules at 2:30am. Time change was at 2:00am so makes sense that while 1:59am works properly, 2:00am does not.

My guess is that it’s related to the way the piston is saved. A schedule for 2:00am is set as the number 120 for 120 minutes past midnight. However, today in EST 120 minutes past midnight happened to be 1:00am rather than 2:00am.

[ady624]

Not sure I can fix this. Here’s what’s going on. Time is stored in UTC through-out webCoRE, it is converted to local when adding deltas, then back to UTC. This is to actually support the DST and correctly work with the Cassandra scheduler within ST. Problem is, however, with the EDT/EST to UTC function not being injective. For instance, 2:00am on the DST removal date (first Sunday of November in the US, last Sunday of October in the EU), has two UTC correspondents, one for when it first reaches 2am, then when it jumps from 3am back to 2am. So there are two UTC timestamps that correspond to what appears to be the same exact time. Converting to UTC and then back to local will give you one of the two possible values (seems to favor the lower one). It’s hard to implement something while still using UTC as a common denominator. Looking into ways to force that UTC time to use the latest timestamp (the one with 1h later).

[smartie]

This all sorta reminds me of the Y2k bug deal…

And this is just a random thought, not even sure if it’s possible, but can we run WebCoRE on a local machine as a back-up, or that wouldn’t even help/be possible? I know this wasn’t a “crash” so to speak, it was the DST screwing things up…but it would be an interesting discussion, nonetheless, if there was a fail-safe back-up (for other issues, not time issues)…

[ady624]

@Kebel871 can you please update the piston app and try again? It should “fix” the offsetting issue… had to do a dirty trick - after converting to UTC, I convert back to local time and compare the time portion - if it’s different, then I subtract the difference from the UTC time, making it work… magic. Black magic.

[MABeatty1978]

I’ve got a bunch of pistons that fire at midnight. They are all showing they are going to fire at 11pm.

[ady624]

Well, the DST screwed up the timing which led to pistons scheduling for past tense, which led to an elevated number of piston runs, which triggered ST alarms, which prompted ST to block said piston code, which led to the pistons not working. Pretty awesome chain of events…

[Snuffy2]

Updated and looks right now. The next fire time now correctly shows 4 AM.