Closed m0uka closed 2 years ago
This should depend on your system time.
The system time is correct, now the schedules are running normally, but if the previous schedule ran without DST, then the next would run +1 hour later, after that everything is normal
Seems more like a bug with the cron library. I don't actually have any particularly special logic that would be the culprit.
Apparently not a bug - https://github.com/mtdowling/cron-expression/issues/116 What about refactoring it to use UTC? I know this is a really minor issue, but it can be annoying and confusing to some people.
Guessing it might be a bug that was long fixed in https://github.com/dragonmantank/cron-expression which is the actual library we use, in which case it will likely end up fixed in coming weeks as we update dependencies and push out those changes.
Guessing it might be a bug that was long fixed in https://github.com/dragonmantank/cron-expression which is the actual library we use, in which case it will likely end up fixed in coming weeks as we update dependencies and push out those changes.
Was this ever looked into / resolved? I'm still seeing this myself in Schedules.
You can see these are actually offset by an hour, and have been since Daylight Savings changed on 03/12/2023.
Current Behavior
Currently, due to the change to daylight savings time, every schedule that was previously executed yesterday was executed an hour later. I am guessing it happens because next_run_at is being set when the previous schedule executes, causing the resulting date to not include DST.
Expected Behavior
The schedule should be executed at the same time every time. Maybe make next_run_at use UTC, so there won't be any problems with DST (make getNextRunDate return UTC, and instead of NOW() use UTC_TIMESTAMP())?
Steps to Reproduce
Panel Version
1.7.0
Wings Version
1.6.1
Games and/or Eggs Affected
No response
Docker Image
No response
Error Logs
No response
Is there an existing issue for this?