RE: calc: function WEEKNUM seems not to conform to ODFF1.2
Hi Eike,
Great we agree :)
Yes, isn't it :)
Note that UI names may (and sometimes do) differ from ODF file format
names, the relation is
UI WEEKNUM == ODF ISOWEEKNUM
UI WEEKNUM_ADD == ODF WEEKNUM
see also formula/source/core/resource/core_resource.src
Resource RID_STRLIST_FUNCTION_NAMES_ENGLISH_ODFF
String SC_OPCODE_WEEK { Text = ISOWEEKNUM ; };
and the sc/source/core/tool/odffmap.cxx entry for WEEKNUM
The mapping Excel WEEKNUM to WEEKNUM_ADD is taken care of in the
import/export filters and Analysis Add-In.
Thank you for your explanation, I will start working on it the next couple of
days.
You'll hear from me :)
Winfried
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
RE: calc: function WEEKNUM seems not to conform to ODFF1.2
Hi Eike, I would like to change the behaviour of function WEEKNUM to conform to ODFF1.2 [...] We might get away with strictly complying with ODFF and generate an error for constraint cases if prominently mentioned in release notes that WEEKNUM changed. Users will have to change formulas then and we get angry mails and bug reports ;-) The other [...] quite more complicated than the first solution and introducing interoperability problems. Therefor I'd go with strict ODFF implementation. I will work on strictly implementing ODFF for WEEKNUM and ISOWEEKNUM. I don't know if I will find a way to produce an error message explaining to the user what exactly is wrong when opening old files with WEEKNUM in it. Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: calc: function WEEKNUM seems not to conform to ODFF1.2
Hi Winfried, On Thursday, 2012-06-07 09:23:47 +0200, Winfried Donkers wrote: I will work on strictly implementing ODFF for WEEKNUM and ISOWEEKNUM. I don't know if I will find a way to produce an error message explaining to the user what exactly is wrong when opening old files with WEEKNUM in it. The wording of your comment https://bugs.freedesktop.org/show_bug.cgi?id=50488#c3 sounds as if you plan to add another function with the name ISOWEEKNUM in the UI. Note that confusingly we already have two functions, WEEKNUM in UI saved as ISOWEEKNUM in ODF and WEEKNUM_ADD (which is the Excel WEEKNUM) in UI saved as WEEKNUM in ODF. I think this might be a plan: * enhance WEEKNUM_ADD to support all ODF WEEKNUM modes * in the UI rename WEEKNUM to ISOWEEKNUM * change ISOWEEKNUM to accept only one parameter * during import's formula compile step for ISOWEEKNUM check if a second argument is provided * if so and if it is a constant value !=1 strip the argument (the Monday case that was and is real ISO 8601) * if it is a constant value ==1 map the function to WEEKNUM * there's a slight chance that a user wanted exactly the behavior ISO but Sunday resulting from the current undocumented implementation details, which isn't supported by ODF WEEKNUM definition, but I think that should be a very rare case, if at all, and is neglectable * if it is not a constant (i.e. computed) argument do nothing and let the interpreter complain about the second parameter I may have to help you with the compiler internals, give me a heads-up when you're stuck there. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpp7SKe9OeoL.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
RE: calc: function WEEKNUM seems not to conform to ODFF1.2
Hi Eike, I think this might be a plan: * enhance WEEKNUM_ADD to support all ODF WEEKNUM modes * in the UI rename WEEKNUM to ISOWEEKNUM * change ISOWEEKNUM to accept only one parameter * during import's formula compile step for ISOWEEKNUM check if a second argument is provided * if so and if it is a constant value !=1 strip the argument (the Monday case that was and is real ISO 8601) * if it is a constant value ==1 map the function to WEEKNUM * there's a slight chance that a user wanted exactly the behavior ISO but Sunday resulting from the current undocumented implementation details, which isn't supported by ODF WEEKNUM definition, but I think that should be a very rare case, if at all, and is neglectable * if it is not a constant (i.e. computed) argument do nothing and let the interpreter complain about the second parameter I may have to help you with the compiler internals, give me a heads-up when you're stuck there. My first reaction is, yes, a good plan and in line with what I wanted to do. I will study your plan carefully, work on it step for step and keep you informed. It looks as if after this plan has been executed, there will be two (in UI as well as ods-file) functions, WEEKNUM_ADD and ISOWEEKNUM, but WEEKNUM_ADD is not defined in ODFF and WEEKNUM is... Shouldn't it be WEEKNUM in the UI and ods-file, and WEEKNUM_ADD in excel-files, to be renamed during export/import? (I haven't thought about implementation issues) Winfried ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: calc: function WEEKNUM seems not to conform to ODFF1.2
Hi Winfried,
On Thursday, 2012-06-07 13:21:01 +0200, Winfried Donkers wrote:
My first reaction is, yes, a good plan and in line with what I wanted to do.
I will study your plan carefully, work on it step for step and keep you
informed.
Great we agree :)
It looks as if after this plan has been executed, there will be two
(in UI as well as ods-file) functions, WEEKNUM_ADD and ISOWEEKNUM, but
WEEKNUM_ADD is not defined in ODFF and WEEKNUM is...
Shouldn't it be WEEKNUM in the UI and ods-file, and WEEKNUM_ADD in
excel-files, to be renamed during export/import? (I haven't thought
about implementation issues)
Note that UI names may (and sometimes do) differ from ODF file format
names, the relation is
UI WEEKNUM == ODF ISOWEEKNUM
UI WEEKNUM_ADD == ODF WEEKNUM
see also formula/source/core/resource/core_resource.src
Resource RID_STRLIST_FUNCTION_NAMES_ENGLISH_ODFF
String SC_OPCODE_WEEK { Text = ISOWEEKNUM ; };
and the sc/source/core/tool/odffmap.cxx entry for WEEKNUM
The mapping Excel WEEKNUM to WEEKNUM_ADD is taken care of in the
import/export filters and Analysis Add-In.
Eike
--
LibreOffice Calc developer. Number formatter stricken i18n transpositionizer.
GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
pgp3WhU57CtMY.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: calc: function WEEKNUM seems not to conform to ODFF1.2
Hi Winfried, On Friday, 2012-06-01 10:07:00 +0200, Winfried Donkers wrote: I would like to change the behaviour of function WEEKNUM to conform to ODFF1.2 (core/tools/source/datetime/tdate.cxx, Date::GetWeekOfYear(..) allows this), but before enter a bug and start working on it, I would like to hear if there are reasons to keep WEEKNUM as it is (and change the documentation to state that the function differs from ODFF1.2). The reason would be exsiting documents that already use a Mode value !=1 and assume that Monday would be used. I think some may pass 0 instead of 2 as argument for this case, as the result of a boolean evaluation. We might get away with strictly complying with ODFF and generate an error for constraint cases if prominently mentioned in release notes that WEEKNUM changed. Users will have to change formulas then and we get angry mails and bug reports ;-) The other possibility would be to introduce an additional ISOWEEKNUM function and map the existing WEEKNUM to ISOWEEKNUM upon reading if and only if the Mode argument is literal and matches the constraints. Writing WEEKNUM then would have to be done as ORG.LIBREOFFICE.WEEKNUM, that couldn't be read by older versions so before actually writing that name at least 2 minor releases must be able to read it already. And of course other ODF consumers would not be able to read it. So quite more complicated than the first solution and introducing interoperability problems. Therefor I'd go with strict ODFF implementation. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD pgpIsGxsaPToS.pgp Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
