AnsweredAssumed Answered

Re-2: vrf ADO Date BUG

Question asked by g.nied on Mar 31, 2005
Latest reply on Mar 31, 2005 by g.nied

> So is it ADO or is it VEE?

I'm pretty sure its VEE.
ADO like VB and .Net uses the OLE Automation Date Format (OADate).
>From MDSN-Website:
"An OLE Automation date is implemented as a floating-point number whose value is the number of days from midnight, 30 December 1899."

If you use ADO in VB and read out the date field with
and R being defined as a real value you can see that R is of the OADate format.
But doing the same in VEE gives us a real value that is in VEE Date Format ( number of seconds since 00:00 hours 1 January 0001 AD)
So there must be a conversion from OADate to VEEDate somewhere. And there is the bug! And this is VEE!
Interestingly if you do the following (senseless) operation inside VEE:
to read out the field value and write it back, no error occurs. Using a variable to store the readout sucks:
Here we add the current timezone offset when in daylight saving time (not 'time saving' as I wrote in my first mail )
Obviously the date conversion does not take place in the first instruction

> Or is it an April Fools joke? So Georg is replying to Georg as Andrew? And
> he's saying something about the file system when we're talking about a
> DbDateTime field in a database? I think we done been spoofered!

Hehe, that confuses you? So you betray yourself being a Bot, huh?

No, as Andrew wrote, he had observed a different daylight saving time related effect regarding the file system. But that has nothing to do with this VEE bug.


Georg Nied  Software-Development  Hansestr. 7  51149 Cologne  Germany
Tel: +49 (2203) 9770915  Fax: +49 (2203) 9770924  E-Mail:

You are currently subscribed to vrf as:
To subscribe send a blank email to "".
To unsubscribe send a blank email to "".
To send messages to this mailing list,  email "". 
If you need help with the mailing list send a message to "".