Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.