now() and time() give wrong time at startup on RasPi Buster

[af0815]

Given a Lazarus programm  with this lines

Code: Pascal  [Select][+][-]

1. procedure TFormMain.ShowTime;
2. var
3.   hstr : string;
4. begin
5.   DateTimeToString(hstr,'hh:mm',time);
6.   LblUhrzeit.Caption:= hstr;
7. end;
8.  

The program is autostarted on a RasPi with Raspbian Buster and show the false time. Look like the timezone is wrong, because it is one hour.
The internal clock of the Raspi is showing at startup also the false time, but after few seconds the time shown is ok, but not inside of the Lazarus prg. When i close the programm and  restart the correct value is shown.

It looks like the the wrong parameters of the time (eg. timezone) is only requested once by Lazarus/fpc and only at startup. Is it possible to force the reload of the time parameters ? Or avoid this issue ?

[Thaddy]

Quite simple: your program is started before the local time resolving daemon. Start time is always UTC, and only when connected to a time resolver (either from a local network or the internet) , not local time. (And for the better)
Can't you solve this by simply adding a cron job? That should start AFTER the OS is finished with its initialization..
Btw: a Raspberry Pi has no real-time hardware clock at all.... You need a $3 hat for that....   Or 50 cents for hardware and 25 cents for a battery .... and a soldering iron...or a conducting glue pen...
Try the time on a Pi that is disconnected from the internet.... I "guess" it is actually 1-1-1970.
Must have something to do with FreePascal, because so many core developers are from the same year, did you know that? 

[af0815]

The time is correct synced after a short time on the RasPi. You can see this on the original clock in the statebar. So it is no problem on the system itself. Timezone and Daylightsaving is interpreted correct. The connection to the timeserver is ok, and no problem with the Ethernet connection.

I have FPC fixes32 and the actual Lazarus fixes20.

When i restart the application it reads and show the correct value. But if the system corrects the timezone or daylightstatus (or similar) the new values are not reloaded.

How can i force the reloading of the timezone daylight and similar infos in Lazarus/FPC.

[Thaddy]

Can you show a little code? because I can not reproduce it and if that really happens I agree there is a serious problem, although that would indicate a problem at the Raspbian side...
I am not busy today and have a lot of these toys.
I haven't tested your previous example on a RPi3, just RPi 4, but I will repeat it.

[edit][modified for readability]
When I reduce your routine to its core, I can not reproduce your issue:
Full program:

Code: Pascal  [Select][+][-]

1. program ShowTime;
2. uses sysutils;
3. begin
4.   writeln(DateTimeToStr(time));
5. end.

Check your code first!

[af0815]

I have found a small hint - this issue is per design !!!

https://www.freepascal.org/docs-html/rtl/sysutils/getlocaltimeoffset.html

Note that on Linux/Unix, this information may be inaccurate around the DST time changes (for optimization). In that case, the unix.ReReadLocalTime unit must be used to re-initialize the timezone information.

[Thaddy]

see my example, posts crossed. But indeed it is the timezone information. This is not only FPC, the Gnu compilers behave the same.
Note that given enough time this will happen automatically since many daemons rely on time information.
Advice is: take a note and be patient...since the Pi has no clock.

[af0815]

The problem is not the missing clock, the problem is, the information is normally never refreshed. But now i know it, and can refresh the tzinformation.

And delay an autostart is also not an easy job :-)

But for me, all is fixed and working now (Without an HW-Clock).

[Thaddy]

the information is normally never refreshed.

That is not true, there is a time out on the sync, about a minute on idle.

[af0815]

the information is normally never refreshed.

That is not true, there is a time out on the sync, about a minute on idle.

No, i have some RasPi running the whole day with different systemtime and time in a Lazarus app. NO Refresh, only restart of the app or now programmed refresh of the settings works (simply call  unix.ReReadLocalTime on a raspi to refresh).

BTW: Your testprogramm cannot show the issue

Code: Pascal  [Select][+][-]

1. program ShowTime;
2. uses sysutils;
3. begin
4.   writeln(DateTimeToStr(time));
5. end.

because every start the information is refreshed.

Make a GUI app, with a timer and call now and show the result
Put this app in a autostart of the desktop

Only now you can see this issue if the dayligth or similar informatiion is changed. The systemclock will reconize the changes after few time, but the app not. Because the app is caching the tzconfiguration and never updating.   

My bad was, the code of mine (first post) is called in a timer every half minute. This was not clear.

[Thaddy]

I can simply not reproduce your issue.

I am very sorry, but this is neither a Lazarus issue nor an FPC issue. I ran my code as a cron job that fires every minute and after a couple of hours the difference is microseconds, in other words, can be neglected. I am not putting any more time in this. At least I tried. And the time is always correct at every start.

[af0815]

It is definitive an FPC problem by design. And documetated, if you find the correct place :-) And i am not talking about seconds or less - i am talking about one hour.

Normally you have only to deal with this if the DST ist changing (actual twice a year). if you have a daemon running 24/7 you must know this.

The problem is, if you use linux like raspbian and using a RasPi without RTC you must know that the DST information (and maybe more) is cached and not refreshed in lifecycle of the app after starting. The goal of the raspi is, he can change the information depending of the information of the NTP and this information is maybe delivered AFTER a autostart.

Today i have seen a diffence between Jessi and Buster. The App was originally designed for/on Jessi, but the new setup is now Buster. And i have seen the issue today only on the Buster RasPis. From Today it is no problem for me, because i make a refresh of the information and so it will be working correct after few minutes.

The electric infrastucture is not so bad in hungaria, so it is no problem, and a reboot from time to time in a greater brownout is no problem for the app. :-)   

 

[avra]

Normally you have only to deal with this if the DST ist changing

Do you catch linux DST change, or you just call ReReadLocalTime() from time to time?

[af0815]

I simply call ReReadLocalTime() from time to time on a RasPi