https://bugs.documentfoundation.org/show_bug.cgi?id=144377
[email protected] changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Ever confirmed|0 |1 Resolution|NOTABUG |--- --- Comment #5 from [email protected] --- > LOL. It does not depend on "my" definition; it is what standard say, and what > is implemented in software. I'm afraid the standard agrees with me. This part of the spec: https://datatracker.ietf.org/doc/html/rfc6350#section-4.3.1 "Reduced accuracy, as specified in [ISO.8601.2004], Sections 4.1.2.3 a) and b), but not c), is permitted." So the ISO8601 specification explicitly says that a date of 1985-04 is valid (it uses that as an example). (Wikipedia says the same thing (with the standard as a ref): https://en.wikipedia.org/wiki/ISO8601#Calendar_dates "The standard also allows for calendar dates to be written with reduced precision. For example, one may write "1981-04" to mean "1981 April". " So hope you don't mind but given the spec itself explicitly says this is a valid date, I'm going to re-open. > There you may specify a Y-M pattern, and then when you enter 2019-01, Calc > will convert it to 2019-01-01 Thanks, but that's false precision (https://en.wikipedia.org/wiki/False_precision) and is exactly the behaviour I do not want (and indeed is probably why the spec does allow reduced precision). -- You are receiving this mail because: You are the assignee for the bug.
