Hi Winfried, On Tuesday, 2015-09-08 10:59:15 +0200, Winfried Donkers wrote:
This appears to be the most complicated change in function names we're tackling because of the different functions AND having an Add-In function involved AND different names for similar but not quite identical functions in UI and file formats.As you know, the problem is that the ODFF function name ISOWEEKNUM is currently used for a function with WEEKNUM functionality.This keep nagging me and I have a suggestion which will make that we lose less time once I start implementing the ODFF1.2 ISOWEEKNUM function: 1. I propose to change the saved function name for the current WEEKNUM function and to add backward compatibility to read saved ISOWEEKNUM and automatically redirect to WEEKNUM.
I'd be delighted if you'd state concrete proposals or at least an
example of what you have in mind.. ;)
So, are you proposing that
* when saving UI function WEEKNUM to ODFF we use another name than the
current ISOWEEKNUM? Like what? WEEKNUM?
* Note that there is also the WEEKNUM_ADD Add-In function, which
currently is written as WEEKNUM.
* Both, WEEKNUM and WEEKNUM_ADD, parameter-wise implement ODFF
WEEKNUM, though only implement modes 1 and 2. With the tweak that
* WEEKNUM with mode != 1 (which unfortunately could also be 0 or any
number, not only 2) actually implements ISOWEEKNUM, just with
two parameters.
* the behavior that the first week of the year starts on January
1 is implemented by WEEKNUM_ADD, if I'm not mistaken.
* both functions currently require 2 parameters, which is not ODFF
conform.
* when reading ISOWEEKNUM map it to UI WEEKNUM?
* That is what we currently do.
* We'd have to change that to
* map to UI WEEKNUM if the file's ISOWEEKNUM has more than one
parameter
* map to new UI ISOWEEKNUM if it has only one parameter, as old
versions would not have calculated with only one and thus probably
the "real" ODFF ISOWEEKNUM is meant
2. This way ISOWEEKNUM will get 'obsolete' in saved documents, making it possible to add the ODFF1.2 IDSOWEEKNUM function to Calc one or more versions after step 1.
The old ISOWEEKNUM probably will never get obsolete, there'll always be
documents that saved UI WEEKNUM as ISOWEEKNUM. Which probably isn't that
bad, given the above mapping depending on the number of parameters
I think we can distinguish enough.
So, having wrapped my head around this ...
Function-wise my proposal is
* keep the Add-In WEEKNUM_ADD implementation as is, and let it get used
when reading/writing old BIFF Excel documents as it is done today
* rename in UI to WEEKNUM_EXCEL2007 or whatever seems fit to point out
it is a legacy function
* store in ODFF as COM.MICROSOFT.WEEKNUM
* store in OOXML as WEEKNUM
* enhance the internal WEEKNUM function to actually implement what ODFF
defines
* store in ODFF as WEEKNUM
* store in OOXML as WEEKNUM
* implement ISOWEEKNUM as defined by ODFF
* store in ODFF as ISOWEEKNUM
* store in OOXML as _xlfn.ISOWEEKNUM
For forward-compatibilty in older still supported LibreOffice branches
* add functionality to map ISOWEEKNUM with one parameter to WEEKNUM with
two parameters, adding a second parameter with value 2 (which for
those implementations means week starting on Monday and first Thursday
is week 1 (the ISO definition)).
Does all that make sense?
I hope I didn't write in riddles ;)
I hope me neither ;) Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GPG key "ID" 0x65632D3A - 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Better use 64-bit 0x6A6CD5B765632D3A here is why: https://evil32.com/ Care about Free Software, support the FSFE https://fsfe.org/support/?erack
Attachment:
signature.asc
Description: PGP signature