Greetings,

There seems to be a bug in the TDateTime data type. When the time difference between two TDateTime variables is just one millisecond, the compareDateTime function returns 0 (equality) rather than the expected -1 or 1 (different). See the included program code.

A program using this TDateTime data type to sort a set of records by descending time stamp gives:

03.09.2015;11:26:15,168;1160265;116026.50;51.010534;3.257746; ... 03.09.2015;11:26:15,068;1320686;135505.23;51.026733;3.123868; ... 03.09.2015;11:26:15,069;1160255;116025.50;50.823928;3.968773; ... 03.09.2015;11:26:14,968;1160245;116024.50;50.964353;2.624580; ...

instead of:

03.09.2015;11:26:15,168;1160265;116026.50;51.010534;3.257746; ... 03.09.2015;11:26:15,069;1160255;116025.50;50.823928;3.968773; ... 03.09.2015;11:26:15,068;1320686;135505.23;51.026733;3.123868; ... 03.09.2015;11:26:14,968;1160245;116024.50;50.964353;2.624580; ...

The record separator is ';'. The first column is the date in (days,months,years). The second column is the time in (hours,minutes,seconds,milliseconds). The time stamp is composed of the first two columns.

The test program prints 0 to the console rather than the expected -1;

My freepascal version is: 3.0.0.
The platform is: Slackware 14.2 x86_64.

Kind regards,
Pascal Pype

Op 31/03/2024 om 11:55 schreef Pascal Pype via fpc-devel:

My freepascal version is: 3.0.0. The platform is: Slackware 14.2 x86_64.

Please try a more recent version (and preferably even the fixes version via FPCDELUXE). Datetime support has detail fixes every release, and 3.0.0 is 9 years old.

Pascal Pype wrote

There seems to be a bug in the TDateTime data type. When the time difference between two TDateTime variables is just one millisecond, the compareDateTime function returns 0 (equality) rather than the expected -1 or 1 (different).

It is fixed in FPC/main (probably in commit
492a0ffcac7035e9f096e353db41bacabedcc91d), not yet in Fixes. Marco, shouldn't this be back-ported?

Op 01/04/2024 om 12:30 schreef Werner Pamler via fpc-devel:

The below revision is marked as merged

*492a0ffcac7035e9f096e353db41bacabedcc91d
<https://gitlab.com/freepascal.org/fpc/source/-/commit/492a0ffcac7035e9f096e353db41bacabedcc91d>* michael Sun Jun 20 08:00:01 2021 r49517 -

* Better precision for samedatetime. Issue ID 0039023 <http://bugs.freepascal.org/view.php?id=39023>, patch by Zoran Vučenović

Yes, you are right. Now I see that it works, after updating my fixes which I should have done earlier.

Yes, you are right. Now I see that it works, after updating my fixes (which I should have done earlier).

Op 01/04/2024 om 17:23 schreef Werner Pamler via fpc-devel:

Yes, you are right. Now I see that it works, after updating my fixes (which I should have done earlier).

Rule of thumb, I merged most fixes in December, except fcl-web/passrc/json/pas2js and some associated packages. Some later revs of the system.ioutils etc units were also intertwined with them.

Merging them was the core goal for me, so that Lazarus could start to use them with FPC 3.4.0 (since then one release back would have been 3.2.4 that had them)

I wanted the begin merging the remaining ones too, but Florian planned to release quickly (but was later thwarted by some arm-linux linking issues that are still pending)

I am using heapmgr but with trunk compiler the value of __heapsize is plain wrong (and way too big)

When I compile my code with my old compiler for pico all is fine, when I debug into heapmgr I see that __heapsize is set correctly to 16384 based on this setting:

program spi_st7789;
{$MODE OBJFPC}
{$H+}
{$MEMORY 16384,16384}

When I use current main compiler the value is 308528 which is more than available memory, this is why I found the issue....

The reason for this is that a line from my original code for linkerfile generation was not included:

       Add('    *(.data .data.*)');
       // Special Section for the Raspberry Pico, needed for linking to spi
*      Add('    *(.time_critical*)');
*      Add('    KEEP (*(.fpc .fpc.n_version .fpc.n_links))');
       Add('    _edata = .;');

and for that reason the content of that section in loaded to start of flash (and during startup to ram) instead of the correct data for __heapsize

Was there a reason for leaving this out when my code was merged to main?

I guess no, so I will create a PR to fix this issue, please comment when there was a reason for leaving this out.

Michael

PR:

https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/638

Probably plain oversight, maybe during conflict resolution or whatever. So please submit a PR to fix it.