[Libreoffice-bugs] [Bug 147316] ODF NUMBERVALUE is too restrictive, disallowing to treat datetimes in locale-independent way
https://bugs.documentfoundation.org/show_bug.cgi?id=147316 m.a.riosv changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #5 from m.a.riosv --- +1 -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147316] ODF NUMBERVALUE is too restrictive, disallowing to treat datetimes in locale-independent way
https://bugs.documentfoundation.org/show_bug.cgi?id=147316 Mike Kaganski changed: What|Removed |Added Severity|normal |enhancement --- Comment #4 from Mike Kaganski --- (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 :-) -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147316] ODF NUMBERVALUE is too restrictive, disallowing to treat datetimes in locale-independent way
https://bugs.documentfoundation.org/show_bug.cgi?id=147316 --- Comment #3 from m.a.riosv --- 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. -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147316] ODF NUMBERVALUE is too restrictive, disallowing to treat datetimes in locale-independent way
https://bugs.documentfoundation.org/show_bug.cgi?id=147316 --- Comment #2 from Mike Kaganski --- (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 :-) -- You are receiving this mail because: You are the assignee for the bug.
[Libreoffice-bugs] [Bug 147316] ODF NUMBERVALUE is too restrictive, disallowing to treat datetimes in locale-independent way
https://bugs.documentfoundation.org/show_bug.cgi?id=147316 m.a.riosv changed: What|Removed |Added CC||miguelangelrv@libreoffice.o ||rg --- Comment #1 from m.a.riosv --- 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. -- You are receiving this mail because: You are the assignee for the bug.
