Hi Sophie,
Just for information changing the date to 01.01.1900 under
tool/options/Calc solved the problem. In fact with the default
30.12.1899, applying a number format to this date #01/01/1900 00:00:00#
return 2 in Calc and it returns 0 in Base.
I don't understand completly why it's different, but it's not a Base
problem but a Calc (or a Sophie) one, so sorry for the noise :)
I'm not quite sure of the exact scenario where you encountered the problem.
In general: If you use the OOo UI to exchange data between Calc and
Base, no matter in which way (drag and drop, linked tables,
copy'n'paste, whatever-you-like), then there should be *no* offset in
dates. If there is, then it's a bug.
If you exchange data programmatically, then it's your own responsibility
to care for dates: Both a data source and a Calc document have a Number
Formatter, which has a NullDate property. Date values, if they're
transported as numeric values such as doubles, are always relative to
this null date.
So, if you have code which obtains a date from a database as double (and
*not* as null-date-independent format, e.g. com.sun.star.util.Date), and
transfer it to some Calc-object (which usually understands only
doubles), then this code has to take the null dates of both participants
into account.
HTH
Ciao
Frank
--
- Frank Schönheit, Software Engineer [EMAIL PROTECTED] -
- Sun Microsystems http://www.sun.com/staroffice -
- OpenOffice.org Database http://dba.openoffice.org -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
