[Libreoffice-bugs] [Bug 143947] Function DATE yields wrong year if input is only "year"

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=143947

--- Comment #7 from Flavius Chiriac <flavius.chiriac at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20210821/ba297eb5/attachment.htm>