Description: The Help about DAYS states: it returns the whole Days without Decimal-fraction. See also: https://forum.openoffice.org/en/forum/viewtopic.php?p=542967#p542967 Steps to Reproduce: 1. Insert Function =DAYS(NOW();DATE(2023;11;1)) Actual Results: It returns 13.8744083253332 Expected Results: 2. It should return 13 Reproducible: Always User Profile Reset: No Additional Info: Version: 7.6.2.1 (AARCH64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Flatpak Calc: threaded
additional: the odf-standard is not exactly clear about whole number or Fraction: http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part2.html#DAYS Can somebody prove the behaviour in Excel?
It is explained in the wiki https://wiki.documentfoundation.org/Documentation/Calc_Functions/DAYS " Details specific to DAYS function The formula for this function is DAYS = Date2 – Date1, subtracting the two date-time serial numbers. This function is not identical to Microsoft Excel’s DAYS function, which does not take account of any time components of the dates. "
It may be explained in the wiki, but NOT in the Help about DAYS!
It is indeed a problem of documentation. Setting the component accordingly. The help needs to mention something like "Calculates the difference between two date values *(including fraction of a day when arguments include time parts)*", or the like. Indeed, the standard is already explicit and exactly clear - it tells "If StartDate and EndDate are Numbers, this is EndDate – StartDate", which provides the exact answer how the result is obtained (no truncation / rounding of arguments and/or result involved).
(In reply to Mike Kaganski from comment #4) > "Calculates the difference between two date values *(including fraction of a > day when arguments include time parts)*", or the like. Or better, explicitly express the difference between numeric arguments (that are used unchanged, and provide fractional result), and textual arguments (that are handled using DATEVALUE, and this truncate). Werner Tietz: please consider a new report regarding introduction of a *new* function, say, DAYS.EXCEL - which would be compatible with what Excel does; usable in import/export (thus improving interoperability); and provide a more useful and consistent behavior.
(In reply to Mike Kaganski from comment #5) > Werner Tietz: please consider a new report regarding introduction of a *new* > function, say, DAYS.EXCEL - which would be compatible with what Excel does; > usable in import/export (thus improving interoperability); and provide a more > useful and consistent behavior. I don't think I want that, we already have more than enough functions in various flavors. My point here is not Excel compatibility, but that: 1. from a function with called "DAYS" I would expect returning the whole days and not also decimal places! Simply because of the behavior of similar functions: MONTHS | YEARS 2. if I also want the decimal places, I simply and pragmatically use =LaterDateTime - EarlierDateTime
(In reply to Werner Tietz from comment #6) INO, you are right in your expectations; the function as it is defined doesn't make much sense. Let's ask Regina's opinion on possibility to radically change the function's definition here. Maybe I exaggerate the problems?
I think, there is a problem in the specification. The parameters of the DAYS function have the pseudo type DateParam (4.11.3.). That has "A DateParam is a value that is either a Number (interpreted as a serial number; 4.3.3)..." Section 4.3.3 is the data type Date. And that has "Date is represented by an integer value." But the implicit conversion to DateParam (6.3.15) has "If the expected type is the pseudotype DateParam, then if value is of type: • Number, return it." That does not include any rounding or truncating to integer. Does someone has Gnumeric to test the result there?
(In reply to Regina Henschel from comment #8) > Does someone has Gnumeric to test the result there? In Gnumeric v.1.12.46: =days(now(),"2024-01-01") returns -47, so it is truncating.