Cron related bugs

[th4git]

Solution/Cause

1. iobroker instance (secondary host; executing the scene adapter) was in fact running on linux system with wrong time zone. Correcting time zone at base system solved the problem described below. So: problem caused by user... :-)
2. Frontend bug seems to be silently fixed at adapter v2.3.9
3. open. Workaround: restart javascript adapter after a change of cron entries at the scenes adapter to keep them in sync.

Describe the bug

1. When using On time (CRON expression) or Off time (CRON expression) ~~at a scene, the created cronjob in the background uses UTC time always and NOT the local time of the system. So if local time (e.g. CET = UTC+1) differs from UTC, the cronjobs do not run at expected hours (time shift).~~
2. When editing an already entered cron time at On time (CRON expression) (Off time works!) the cursor always jumps to the line end after entering one new character/single digit.
3. Severe Bug: CRON expression at a scene is not correctly cleared from system CRON if scene is disabled or scenes CRON expression is changed or removed.

To Reproduce

1. Setup local time different from UTC (e.g. CET). Setup cronjob at scene at specific hour like * 0 10 * * * The job will not run at 10:00 (CET = UTC+1) but in fact at 9:00 (UTC).
2. Create scene with On time (CRON expression) = * 0 10 * * * Mark the minutes "0" with mouse cursor to overwrite it. Type new digits "23". The field will show up On time (CRON expression) = * 2 10 * * *3
3. Setup a scene using CRON as follows to run it every 2 seconds: On time (CRON expression) = */2 * * * * * Save it. Wait 5 seconds until initzialization finishes. Scene now runs every 2 seconds. Now disable this scene. From now on the log shows up with an error every 2 seconds until scene ist activated again or javascript adapter restarted. Even entering an empty or new CRON expression at the scene and saving it will not stop the old cron schedules and their errors at the log.

Expected behavior

1. Jobs scheduled should run at local time not UTC.
2. Entering multiple digits/characters at cursor position should all show up there in a row. At the example above On time (CRON expression) = * 23 10 * * *
3. CRON activities are disabled if scene is diasbled and removed completely if scenes CRON config is reverted to be empty again and set to new the cron values only if changed.

Screenshots & Logfiles

1. The debug logfile ´reflects the (local) time set at scene correctly debug Initiate cron task for scene.0.TestScene(true): * 0 10 * * * but schedule runs at UTC.
2. Only video may show behavior. ;-)

3. 
   scenes.0 2021-12-13 09:21:44.345    error   Unexpected error: Scene "scene.0.TestScene" does not exist!
   scenes.0 2021-12-13 08:21:42.354    error   Unexpected error: Scene "scene.0.TestScene" does not exist!
   scenes.0 2021-12-13 08:21:40.342    error   Unexpected error: Scene "scene.0.TestScene" does not exist!

**Versions:**  
Adapter version: 2.3.8
JS-Controller version: 3.3.18
Node version: v14.17.5
Operating system: Raspbian GNU/Linux 10 (buster) on RaspberryPi 4

Would be great to see this fixed at this wonderful adapter! :-)

[Apollon77]

I think the "local time of your OS" is the relevant one ... so whats up there? What "date" tells yoi? Else set the timezone there correctly first!

[th4git]

You are right regarding the incorrect time zone settings: My iobroker setup runs two instances: one primary and one secondary instance. Primary had correct CET time zone, secondary (where scene adapter is assigned to) was running on GMT - now corrected.

Now only the second bug mentioned above is still relevant. :-)

[Apollon77]

Can you then please edit above that it is clear in the initial post? Thank you!

[th4git]

Any progress so far? Additional info or support needed?

[th4git]

Frontend bug (No. 2) seems to be silently fixed at adapter v2.3.9. Bug No. 3 (entered cron actions at system deamon are in fact not changed/deleted) is still open (re-verified again). @GermanBluefox or @Apollon77 : Would be great to get this fixed.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs within the next 7 days. Please check if the issue is still relevant in the most current version of the adapter and tell us. Also check that all relevant details, logs and reproduction steps are included and update them if needed. Thank you for your contributions. Dieses Problem wurde automatisch als veraltet markiert, da es in letzter Zeit keine Aktivitäten gab. Es wird geschlossen, wenn nicht innerhalb der nächsten 7 Tage weitere Aktivitäten stattfinden. Bitte überprüft, ob das Problem auch in der aktuellsten Version des Adapters noch relevant ist, und teilt uns dies mit. Überprüft auch, ob alle relevanten Details, Logs und Reproduktionsschritte enthalten sind bzw. aktualisiert diese. Vielen Dank für Eure Unterstützung.