On 01/19/2012 09:03 PM, Andrew Douglas Pitonyak wrote:
On 01/16/2012 08:01 AM, Eike Rathke wrote:
Hi Noel,
On Friday, 2012-01-13 09:51:33 +0000, Noel Power wrote:
this change ( the variant ) is what is on master, here the
intention is as Andrew pointed out ( in a previous mail discussing
the regression ) to allow operations on date types return dates (
regardless of the operation ) which seems reasonable.
Not every operation on date types should return a date, i.e.
substracting two dates should return a number of days (I don't think
adding/multiplying/dividing two dates makes sense, but it should return
a number of days as well).
Eike
The original code verified that a date was used in at least one
argument, and, if so, then a date is returned. Eike, to follow your
suggestion of NOT returning a date if we expect that the answer should
be a number of days, then we would want to check both parameters, and
if both are of type date then return a double rather than date. If you
really desire to strive for accuracy, then what you want to say is
that if two dates are involved and there is a subtraction, then you
desire the elapsed time between the two date objects.
I need to be careful in what I say because I am not intimate with the
code, but, I believe that a date is internally represented as a
double. I also seem to remember that a "time" is a date that has "zero
days". This leaves a day that cannot be represented (well, it won't
print as a date anyway, at least I think it did not when I last tested
it long before LibO existed).
One may choose to argue that date arithmetic makes no sense (ie, what
does it mean to add today to today, or to multiply today by 2), but I
believe that the original solution was written to allow for the common
case and do the expected thing. So, Perhaps I have code such as
(time_1 + time_2 - time_3), the intent seems to be to determine the
difference between time_2 and time_3 and add that to time_1. In the
original code, that would work. I suppose that if we add a check to
verify that one parameter is a date and that the other is not, then
our result would be mostly as expected, but that feels onerous. It is
a bit difficult and fraught with peril, however, because I believe
that if the new time passes midnight (ie, 24 hours), then it will
suddenly display as a date rather than a time.
Oh my.... Looks like Date and Time are represented as different types
internally.
--
Andrew Pitonyak
My Macro Document: http://www.pitonyak.org/AndrewMacro.odt
Info: http://www.pitonyak.org/oo.php
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
