Reproduced on version 7.3+.

It seems a value in DATE function defaults to 0 if no number is given. It seems MS Excel acts in the same way.

Should the default value be 1 instead of 0? In that case the expected result for the all given examples should be 2006-01-01.

Currently, the value 0 in DATE function gives the previous value of 1 that is 12 for the case of month and in the case of day it is the last day of previous month.

From my understanding of LibreOffice Help - Calc (https://help.libreoffice.org/latest/en-US/text/scalc/01/func_date.html?DbPAR=CALC#bm_id3155511) - none of the parameters "(Year; Month; Day)" is _optional_ (no square brackets being used). In that sense, I don't see a bug here.

(In reply to Henrik Palomäki from comment #1)
> Reproduced on version 7.3+.

Please don't set up yourself as 'new', other person must do it, except you are a developer assigning.

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?

(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	0	1	2005-12-01	=DATE(A3;B3;C3)
2006	-1	1	2005-11-01	=DATE(A4;B4;C4)
2006	-2	1	2005-10-01	=DATE(A5;B5;C5)
2006	-3	1	2005-09-01	=DATE(A6;B6;C6)
2006	-4	1	2005-08-01	=DATE(A7;B7;C7)
2006	-5	1	2005-07-01	=DATE(A8;B8;C8)
2006	-6	1	2005-06-01	=DATE(A9;B9;C9)
2006	-7	1	2005-05-01	=DATE(A10;B10;C10)
2006	-8	1	2005-04-01	=DATE(A11;B11;C11)
2006	-9	1	2005-03-01	=DATE(A12;B12;C12)
2006	1	0	2005-12-31	=DATE(A13;B13;C13)
2006	1	-1	2005-12-30	=DATE(A14;B14;C14)
2006	1	-2	2005-12-29	=DATE(A15;B15;C15)
2006	1	-3	2005-12-28	=DATE(A16;B16;C16)
2006	1	-4	2005-12-27	=DATE(A17;B17;C17)
2006	1	-5	2005-12-26	=DATE(A18;B18;C18)
2006	1	-6	2005-12-25	=DATE(A19;B19;C19)
2006	1	-7	2005-12-24	=DATE(A20;B20;C20)
2006	1	-8	2005-12-23	=DATE(A21;B21;C21)
2006	1	-9	2005-12-22	=DATE(A22;B22;C22)
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

(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?

According to comment 2 Excel yields the same result for DATE(2006;;) (or DATE(2006,,) depending on function parameter separator), so nothing to change here.