[DUG] DateTime Floating Point Errors.

[Kyley Harris]

Yep. I am discarding my milliseconds. The problem I had was a re-encoding data.

ie
               'yyyymmddhhnnsszzz
  String = '20050101000000000';

converting the time portion using EncodeTime(0,0,0,0) does not return 0.0
but RecodeMilliseconds(EncodeTime(0,0,0,0) , 0) does return 0.0

it is bizzare, but Mr Sherlock link does make it comprehensible I
guess. Would have been nice for encode time to force rounding properly
though ;)


On 10/24/05, John Bird <johnkbird at paradise.net.nz> wrote:
> I am guessing you are keeping the milliseconds for a reason, but otherwise
> throw them away - I lose the milliseconds every time I convert a date/time
> unless I am actually using them for a timing loop.
>
>   Eg  formatDateTime('dd mmm yyyy hh:nn:ss',dtDateTime);
>
> I would imagine in general its good to be cautious about a test like
>
>    if FloatVariable = AConstantValue
>
> As there is so many ways it could fail if its not quite the same (for
> instance even a different compiler version etc might cause code to fail..)
> (This is probably one of the reasons I still do lots of this sort of stuff
> with integer and int64 variables.....but then I am a bit of a luddite from
> way back)
>
> There is a similar but unrelated effect with filedatetime, where if you use
> a filedatetime on two files to check if a file needs to be copied if one has
> been changed the check will often fail if the 2 files are stored on
> different types of file system (eg NTFS and FAT32 for instance as these have
> different resolutions for file time modifications), so a file copied from
> one to the other doesn't end up with exactly the same modification
> date/time.  To do it properly you need to allow two files with modification
> times up to 10 seconds apart to be assumed to be the same (2 in theory but
> 10 is safer I found).  I have been meaning to write a routine to copy files
> if the dates are different taking this into account...but haven't yet, I am
> hoping someone else out there has and will pop up brightly and say here is
> one!
>
> John
>
>
> -----Original Message-----
> From: delphi-bounces at ns3.123.co.nz [mailto:delphi-bounces at ns3.123.co.nz] On
> Behalf Of Kyley Harris
> Sent: Sunday, 23 October 2005 7:26 p.m.
> To: NZ Borland Developers Group - Delphi List
> Subject: [DUG] DateTime Floating Point Errors.
>
>
> I wonder if anyone else has noticed this irritating rounding issue on
> datetimes.
>
> Bear in mind that this is not a useful answer is you care about historical
> dates. I only care about dates greater than the year 2000.
>
> Problem. When comparing an "empty date" (meaning Date = 0.0) delphi behaves
> differently on different computers meaning that my if varDateValue = 0.0 can
> return false a lot of the time. This is also the same when comparing Dates
> that have a zero time factor.
>
> on my computer, EncodeDate(1899,12,30) + EncodeTime(0,0,0,0) does not return
> 0.0, but something along the lines of zero + an infintesimal fraction that
> does not equal zero any more.
>
> I solve my problem with the following method of forcing a date when setting
> a date property.
>
>   if DateTimeValue < ZeroDateThreshold /* EncodeDate(1900,1,1) */  then
>   begin
>     result := 0.0;
>   end else
>   begin
>     result := RecodeMilliSecond(result,0);
>   end;
>
> This forces a removal of all these little tiny bits of rubbish on the end of
> my datetimes that occurs when I convert my string dates "yyyymmddhhnnsszzz"
> into real date etc.
>
> anyone got better ideas? if not.. hope this helps anyone else.
>
>
>
> --
> Kyley Harris
> Harris Software
> +64-9-8455274
> +64-21-671-821
>
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz http://ns3.123.co.nz/mailman/listinfo/delphi
>
>
> _______________________________________________
> Delphi mailing list
> Delphi at ns3.123.co.nz
> http://ns3.123.co.nz/mailman/listinfo/delphi
>


--
Kyley Harris
Harris Software
+64-9-8455274
+64-21-671-821