> 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).
"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: email@example.com
You are currently subscribed to vrf as: firstname.lastname@example.org
To subscribe send a blank email to "email@example.com".
To unsubscribe send a blank email to "firstname.lastname@example.org".
To send messages to this mailing list, email "email@example.com".
If you need help with the mailing list send a message to "firstname.lastname@example.org".