Now function gives back wrong time

[jollytall]

I have the simplest program:

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

1. program nowprogram;
2. uses  SysUtils;
3. begin
4.   writeln(DateTimeToStr(Now));
5. end.  

I run it on two different machines, both with Debian 10, in the same timezone, with NTP, etc. Still one gives the correct time, the other gives one hour more. I could not figure out what can go wrong.

A bit of background: I wanted to get back the TZ offset for IdGlobal Indy, what is not implemented under Linux. I found (see few post below) a LazUtils utility and a function NowUTC that gives back the UTC time. So I ran it (Now-NowUTC) and got the wrong result. I thought first that the new and complex NowUTC is the guilty one, but it turned out that that is correct and the basic Now is wrong.
(I have the TZ set correctly, but actually that does not matter, even if it were set to anywhere, Now should give back the local time, seen in the OS GUI.)

[winni]

Hi!

One of your Debian is allowed to behave like a Windows machine and set the time to the local TimeZone.

The other machine behaves in the standard Unix/Linux mode: the clock is set to UTC.


In my eyes the first is a misconfiguration.

Anyway: In the unit  LazSysutils exists the function

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

1. function NowUTC: TDateTime;

And there  is the package Pascal TimeZones. Read more:

https://wiki.freepascal.org/PascalTZ


Winni


PS.:

How to Set or Change Timezone on Debian 10:

https://linuxize.com/post/how-to-set-or-change-timezone-on-debian-10/

[MarkMLl]

I've not seen that on Debian, and a year or so ago I did a lot of prodding at different ways of getting time information and reconciling seconds-since-epoch etc.

However I would say that I don't think much of the way that Now() returns something which is basically a 64-bit floating-point number, since the further we move from the epoch the fewer bits are available for the fractional part. And I /know/ that that's graven in stone due to Delphi etc., and I /still/ don't think much of it: at the very least the calculations should try to use the platform-specific extended type internally.

MarkMLl

[winni]

Hi!

I have seen a lot of misconfigured Debian machines concerning the timezones.
Just had a fresh setup Debian machine some days ago which was one hour away. Everything setup by default.

As the TDateTime is a Double you can compute with dates in every way.
But be warned of the Delphi-compatible converting functions. There is a lot of nonsens.

If
Date1 -Date2

is in th range of 0..99 days then Delphi/Lazarus adds the year 1900.

And a lot of other rubbish.

Write the convert functions yourself.

Basic unit is: A day is One.
An hour is 1/24
A minute is 1/(24*60)
A second is 1/(24*60*60);

The rest is trivial.

Winni

[jollytall]

@winni
The two systems are set-up as much as possible the same way. timedatectl command in Linux gives exactly the same result for all the values. Also ls -l /etc/localtime gives the same and correct timezone on both machines. It is true that some time back I changed timezones on the "bad" machine, but at the moment I do not see any difference. Where can I check if my Linux really thinks in a "Windows way" and how can I change it?
If it is so, shouldn't the bad machine give back the UTC as the local time? It is not the case. The local time is UTC + 0200, while the misbehaving machine gives UTC + 0300. Furthermore it is not even the non-DST, as that would be UTC + 0100.
I do not understand what you mean with NowUTC. As I wrote, I know it and use it, and that gives a correct time on both machines. I need both Now and NowUTC as the easiest way to know the offset (Now-NowUTC).
I still do not see how Now() can give something else than the local time.

@MarkMLI
I do not think it is a number format, bitlength error. It gives the correct minute/second just one hour wrong.

@winni (2)
Thanks, but the calculation is correct. It is simply Now() being wrong.
Where can you see that your system is one hour away? I can have the same problem, but as said above, I do not see anything wrong.

[winni]

Hi!

Strange.

The simplest way is using the bash:

This gives you the local time:

Code: Bash  [Select][+][-]

1. date

And this tells you the UTC

Code: Bash  [Select][+][-]

1. date -u

My correct result is there are 2 hours difference:

1 for Central Europe an 1 for daylight saving.

Winni

[winni]

To demonstrate the old Delphi nonsense which Lazarus uses we show very simple code

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

1. procedure TForm1.Button1Click(Sender: TObject);
2. var date1,date2: TDateTime;
3. begin
4. date1  := EncodeDate(2021,8,1);
5. Date2 := encodeDate (2021,8,15);
6. showMessage (DateToStr(Date1-Date2) + LineEnding + DateToStr(Date2-Date1) );
7. end;            

This results ins

16-12-99
13-1-00

But don't tell the headquater this is nonsense.

It is not because it is Delphi compatible!!

Winni

[jollytall]

Here are two screenshots. The same commands, same "nowprogram", different results.

I understand the Delphi nonsense, but in these examples there is no difference, only plain Now().

[winni]

Hi!

Use  timedatectl on the bash. And compare if the two machines give the same result.

In my case it results in:

Code: Bash  [Select][+][-]

1. timedatectl
2.                Local time: Mon 2021-08-23 22:38:55 CEST
3.            Universal time: Mon 2021-08-23 20:38:55 UTC
4.                  RTC time: Mon 2021-08-23 20:38:56
5.                 Time zone: Europe/Berlin (CEST, +0200)
6. System clock synchronized: yes
7.               NTP service: active
8.           RTC in local TZ: no
9.  

Winni

[jollytall]

Winni,
As said above:

timedatectl command in Linux gives exactly the same result for all the values. Also ls -l /etc/localtime gives the same and correct timezone on both machines.

Theses were the first two things I checked and both give the same and correct results, just like date and date -u.
The only thing that gives a different result is the one line pascal program in the OP.

[winni]

Hi!

Stange, strange, ...

Somewhere a bit in the RAM hit by hard rays from the sun?
Happens with every PC 6 times in 24 hours.
Most times nothing realy important is change: A bit in unused space, a pixel in an Icon,  an unexspected keypress, and and...

But sometimes it can result in such a strange thing.

I've got no other idea: reboot both machines.

If the problems persists then we have a hard job.

Winni

[winni]

Hi!

And one Debian is a RasPi???

Andreas from Vienna had the same problem:

https://forum.lazarus.freepascal.org/index.php?topic=47317.0


I don't know nothing about kindergarden computers.

Winni

[jollytall]

Well, it is under the table, so not much sun :-)

But anyway I have just restarted it and got the same error:

Code: Bash  [Select][+][-]

1. $ timedatectl
2.                Local time: Mon 2021-08-23 23:08:40 CEST
3.            Universal time: Mon 2021-08-23 21:08:40 UTC
4.                  RTC time: Mon 2021-08-23 21:08:40
5.                 Time zone: Europe/Budapest (CEST, +0200)
6. System clock synchronized: yes
7.               NTP service: active
8.           RTC in local TZ: no
9. $ ./nowprogram
10. 24-8-21 00:08:45

The only difference, though it should not matter that the program is compiled once on the good machine and copied to the bad one. Can it link a library not compatible with the other??? I don't think so. If not likely, I would not start installing Lazarus on it.

@latest post
I had read earlier the rPi problem when searched the forum, but it is not a rPi (anyway that is because rPi has no battery clock, so until it is not set/synchronised it does not know the time). Mine is a 64bit desktop (bad one) and a 64 bit laptop (good one). So, again, the program is the same on binary level, not a different compile from the same source.

[MarkMLl]

And one Debian is a RasPi???

Andreas from Vienna had the same problem:

https://forum.lazarus.freepascal.org/index.php?topic=47317.0


I don't know nothing about kindergarden computers.

Shouldn't make a difference. The only detail is that the RPi's kernel doesn't have a valid time until it's been able to get one using NTP, ... ... that could I suppose impact the detail of DST correction if the kernel's trying to get some configuration detail from non-existent BIOS CMOS.

MarkMLl

[sstvmaster]

Can you try to remove the bios battery or set the bios clear jumper? Or maybe bios update helps?