https://bugs.documentfoundation.org/show_bug.cgi?id=143947
--- Comment #7 from Flavius Chiriac <flavius.chir...@gmail.com> --- (In reply to Uwe Auer from comment #6) > (In reply to Roman Kuznetsov from comment #5) > > Eike, I don't think it's a bug, but if user doesn't enter any from mandatory > > arguments, then Calc should shows some error code. Could you take a look at > > it? > > Let's break down: > > 1) Omitting parameters cause an error: Using =DATE(2006)result in Err:511 > "Variable missing" as expected. > 2) Using =DATE(2006;;) translates to =DATE(2006;0;0)and now we have OASIS > Standard (see [1]) stating: > > Constraints: 1904 ≤ Year ≤ 9956; 1 ≤ Month ≤ 12; 1 ≤ Day ≤ 31; Evaluators > may evaluate expressions that do no meet this constraint ... Month > 12 and > Day > days of Month will roll over the date, computing the result by adding > months and days as necessary. > > Now obviously evaluators decided to compute date backwards accordingly if > Month < 1 and Day < 1 (i.e. subtracting months and days as necessary). > > Year Month Days Date Formula > 2006 1 1 2006-01-01 =DATE(A2;B2;C2) > [...] > 2006 1 -10 2005-12-21 =DATE(A23;B23;C23) > > 1) Don't see a bug here > 2) Don't see a violation of the standard, but an allowed interpretation what > to evaluate in case of a constraint is not met > 3) There is an error in case missing argugemt > 4) The only thing to dispute may be, whether implicit translation of > =DATE(2006;;) into =DATE(2006;0;0)is covered by the standard. > > > [1] OpenDocument-v1.3 - 6.10.2 DATE > https://docs.oasis-open.org/office/OpenDocument/v1.3/os/part4-formula/ > OpenDocument-v1.3-os-part4-formula.html#__RefHeading__1018174_715980110 a) thanks for the detailed "case study" b) thank for pointing towards some kind of standard ([1]) c) in terms of whether DATE(2006;;) should yielding at least the correct year (see 4) from last post): I would argue that this would be an intuitive behaviour; sometimes we may want to put only the year. However, I'm not knowledgable enough to know whether changing this would be feasible or whether it'd be better to stick with the standard. if it were up to a vote, I'd vote that yes, it should output the correct year. since however i'm not a developer and also not foreseeing all the consequences and possible relations to other functions, i would not protest if someone convinces me reasonably enough that it would be better to leave it as it is. ergo: perhaps it's not a bug but a desired feature for future releases? in that case some admin please update the status accordingly or link to the developers. In terms of general improvement of calc - the more intuitive, the better, no? -- You are receiving this mail because: You are the assignee for the bug.
