On 6/1/02 8:06 AM, Roger Carey wrote:
> Using RB 4.0.2:
> If using ParseDate("7/4/1776",d)
> d.TotalSeconds = 18446744065391368192 (using format (d.totalseconds,
> "#.0;-#.0"))
>
> Then the d.shortdate + " " + d.longtime is 07/03/1776 11:57:51 PM
>
> The TotalSeconds is a double. It is more digits (20) than a double can
> handle (16+?). I think this accounts for the difference between
> 07/03/1776 11:57:51 PM and 7/4/1776 12:00:00 AM.
Which raises a question in my mind as to what exactly the TotalSeconds is
_supposed_ to be in dates prior to Jan 1, 1904 (since the docs state that
the TotalSeconds property is the number of seconds _since_ Jan 1, 1904).
Even the examples in the LR for the ParseDate function (which takes a Date
object as the second parameter) use a date of 1341; yet, the only
documentation for the Date class states that TotalSeconds are since Jan 1,
1904. Not very clear at all, unless I'm missing something...
> It looks like they are using an integer for total seconds in the Date
> class, but forgetting about the negative bit for the total seconds
> property when changing it to a Double.
Dunno, but I doubt that's the problem.
> Anyone know of a workaround?
I haven't tried this, but could you use a century offset to make all of your
dates _after_ Jan 1, 1904 in order to preserve accuracy? In other words,
just add 200 (or something) to your centuries before passing them to
ParseDate. Then subtract that offset before displaying them. You could
probably package all that functionality in a custom OldDates class or
something.
Just a thought...
---
Steve Schacht
shot at frontier dot net
|