@nsmith I'll explain it like this. If I switich on the device and manually set the date and time to July 2nd, 2022 11:22:30 and leave the device running, it will keep the correct time with no need for any network/internet access, so at 15:25;12 on July 2nd 2022 I check the time and find the date and time to be correct. Then I switch the device off. On July 2nd 15:55:12 I switch the device back on. What will the date and time be? The answer is not as you might expect, it is not July 2nd 15:55:12. This is because the device stores the date and time in volatile RAM, so when the power is removed this is lost. When the device starts up it attempts to correct the date and time using a script /etc/init.d/sysfixtime which looks for the latest timestamp on files in /etc, of course if none of these files have changed in months then this doesn't help much. You could run a cron job that touches a file in /etc every X number of minutes/hours, but again if your device is switched off for day you'll still lose a day on the clock. Also touching files in /etc too frequently is not a great idea as it increases wear on the RAM. If your requirement is to simply track the duration of something regardless of whether the date and time are correct you can still do this. For example when your app starts up it might check the date and time (even if it is not correct), then later it could check date & time again and calculate the time difference between these two checks, just not the actual date and time. I hope that helps.

@CAP-33 Try date -s YYMMDDhhmm.ss (eg. with date command of BusyBox v1.28.3). date -s 1904071301.00 Sun Apr 7 13:01:00 GMT 2019 If the date command of BusyBox is not enough for you then install the coreutils-date package - it's theoretically a full version of the standard GNU date utility. (As you know well: enable the 5th line of '/etc/opkg/distfeeds.conf', opkg update and opkg install coreutils-date.) date -s '19-04-07' Sun Apr 7 00:00:00 GMT 2019 To change only the date you can use shell command substitution in the date string: date -s "19-04-07 $(date +%H:%M:%S)" it will change the date and keep the time. # Omega2 Pro (light) FW v0.3.2 b218 root@Omega-5BE1:/# date -s '19-04-07 13:01:00' Sun Apr 7 13:01:00 GMT 2019 root@Omega-5BE1:/# date Sun Apr 7 13:01:02 GMT 2019 root@Omega-5BE1:/# date -s '19-04-07' Sun Apr 7 00:00:00 GMT 2019 root@Omega-5BE1:/# date Sun Apr 7 00:00:02 GMT 2019 root@Omega-5BE1:/# date -s '19-04-07 13:01:00' Sun Apr 7 13:01:00 GMT 2019 root@Omega-5BE1:/# date Sun Apr 7 13:01:02 GMT 2019 root@Omega-5BE1:/# date -s "19-04-07 $(date +%H:%M:%S)" Sun Apr 7 13:02:21 GMT 2019 root@Omega-5BE1:/# date Sun Apr 7 13:02:09 GMT 2019

@cas As you know @Lazar-Demin (I think he is the firmware maintainer) should update the TZ strings in the onion command line tool occasionally because some of them becomes outdated from time to time. BTW There are "updated" OpenWrt TZ strings here and you can see the TZ string of Europe/Moscow has already corrected (but - for example - the TZ string of Europe/Istanbul has not).

Thanks! I just experienced this problem. I was about to post a new topic, but your solution saved me. I did opkg install zoneinfo-europe. It was weird. My code was working fine, then suddenly stopped. I wonder if it was to do with the timezone change to BST here in the UK at the weekend?

@Frederic-Baumann Yes, agreed. Sorry I missed your earlier reference to line 202 in zonenamePromise - that is exactly what I had found too. Though changing the code to what I think it should be still doesn't work properly for me. I will dig further and let you know how it goes.

@Lazar-Demin @Lazar-Demin said: @Seth-Stone It's looking really Cloudy today, I would keep my ears open haha the puns!