ODF defines NUMBERVALUE to only treat valid xsd:float [1]. This disallows e.g. this: =NUMBERVALUE("2022-02-09 13:50:25.1234";".";"") which would allow to process datetime values with specified decimal separator used for second fraction. Note that Excel allows at least NUMBERVALUE("2022-02-09"). [1] https://docs.oasis-open.org/office/OpenDocument/v1.3/OpenDocument-v1.3-part4-formula.html#NUMBERVALUE
Are you sure it's supposed to do that? Seems NUMBERVALUE it's only about numbers, not dates or dates-time, and looks that the second parameter it's for the thousand's separator. DATETIME and VALUE, do that, but those have local dependency without options.
(In reply to m.a.riosv from comment #1) > Are you sure it's supposed to do that? Heh, I suggested an improvement, not wrote it was supposed to do that from the beginning :-)
I see, but as it is not as enhancement, I was misinterpreting. In any case, IMO VALUE() looks a better function for that, as it is already interpreting dates, only needs support for decimal separator. Even best if VALUE() tries first the separator of the language in use, and if error result with the other. For me excel NUMBERVALUE() doesn't work in that way for dates. Only works for dates without time and without parameters.
(In reply to m.a.riosv from comment #3) > In any case, IMO VALUE() looks a better function for that, as it is already > interpreting dates, only needs support for decimal separator. > Even best if VALUE() tries first the separator of the language in use, and > if error result with the other. No. Trying different separators one after another is error-prone. E.g., some locales have comma and dot pair; other locales (e.g. ru-RU) have comma and space... and trying several variants would just increase likelihood of false detection. Note that NUMBERVALUE is *specifically* created for locale-independent conversion; and this is exactly the context of this enhancement - when user wants to convert the input from specific representation, without taking current locale into account. Extending VALUE to accept fractions of a second is separate issue, and should only use current locale. However, it would also be OK to introduce a dedicated VALUE_* variant for locale-independent conversion, or to add optional arguments to override the separators ... no idea what would be better, but it would work, too. > For me excel NUMBERVALUE() doesn't work in that way for dates. Only works > for dates without time and without parameters. Yes, that is what I mentioned :-)
+1