hi Regina, On 17/10/2023 19:17, Regina Henschel wrote: Hi all, as suggested in the meeting I sent you the current state of my work. It shows my proposed solution for the case, that we decide to use new functions for 'rounding before extracting'. The idea of using a dot in the function name comes from Michael. I like that idea. It makes the function names good readable. yes, and there are already several functions with a . in the name. I have added a new pseudotype DateTimeParam. That makes it possible to give YEAR.ROUND a different behavior than YEAR, for example. The proposal does not introduce a DATETIMEVALUE.ROUND function as suggested by Michael, but uses the VALUE function directly. Comments are welcome. thanks, mostly looks good to me! Evaluators shall support extracting the year from a date beginning in 1900. Three-digit year numbers precede adoption of the Gregorian calendar, and may return either an Error or the year number. Four-digit year numbers preceding 1582 (inception of the Gregorian Calendar) may return either an Error or the year number. Four-digit year numbers following 1582 should return the year number. the new text does not allow implementations to return an Error for a pre-Gregorian date, do we know if that is a problem for any existing implementation? If the serial number given in D represents a date before 1852-10-15 (adoption of the Gregorian calendar) then Evaluators may return an implementation-defined year number. the "1852-10-15" has a typo, the year should be 1582. A formal definition of term serial number is missing. not sure, i think it becomes obvious enough if you search the specification for "serial", but maybe that means it's not obvious enough. A text can describe a date in content, but use a non-Gregorian calendar. How is that handled? i don't want to open that can of worms :) Should the specification force, that the serial number of a date is interpreted using the Gregorian calendar, if the date represented by the serial number is after 1582-10-15 (inclusive)? no, because there is already an optional "Capability" for this: 7.4 Year 1583 Evaluators claiming to implement Year 1583 can correctly calculate dates correctly starting from the January 1 of the (ISO) year 1583. (editorial: one "correctly" is enough?) regards, michael -- Michael Stahl Senior Software-Entwickler LibreOffice allotropia software GmbH Versmannstr. 4 20457 Hamburg Germany
michael.stahl@allotropia.de https://www.allotropia.de Registered office: Hamburg, Germany Registration court Hamburg, HRB 165405 Managing director: Thorsten Behrens VAT-ID: DE 335606919