Problem description: Function FileDateTime returned error value. Steps to reproduce: 1. MsgBox FileDateTime("C:\1.txt") Current behavior: renurned DD.04.YYYY 14:00:06 Expected behavior: renurned 01.04.2013 14:00:06 Operating System: Windows 7 Version: 4.0.2.2 release Last worked in: 3.6.5.2 release
I confirm this bug, I have no error but the return is: 11/10/jeudi 11:56:04 where I expect for 06/10/2011 11:56 Version 4.0.2.2 (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3) Vista-32b Language settings: French It works fine with 3.6.6 Importance High and Major because previous programs can not work
Wondering whether commit 438efb38ec42f9c342342925236cf8ea1eada9fc is responsible ? Ading Andras to CC.
Hello I confirm with Windows XP Pro & Version 4.0.1.1 (Build ID: 2c0c17a6e4bee0ee28131ea4bdc47edc700d659) Regards Pierre-Yves
(In reply to comment #2) > Wondering whether > commit 438efb38ec42f9c342342925236cf8ea1eada9fc > > is responsible ? > It is on master only and the bug was found in 4.0, so it's not possible.
I think that at http://opengrok.libreoffice.org/xref/core/svl/source/numbers/zformat.cxx#3850 const ImpSvNumberformatInfo& rInfo = NumFor[nIx].Info(); rInfo contains corrupted data, maybe as a consequence of mass String->OUString conversion between 3.6 and 4.0. I could not debug it properly, but I saw strange things. For example when the date separator should have been inserted, the corresponding string from rInfo contained "/DD/YYYY " instead of "/" with en-US locale. For other locales the behavior was different, but also wrong.
Might be, I'll take a look. The display string "DD.04.YYYY 14:00:06" looks as if an English format code string was used with a locale that has localized different day and year codes and not D and Y. @Vladimir: what is your locale? "11/10/jeudi" instead of "06/10/2011" in fr-FR locale would be the result of AA/MM/JJJJ or AA/MM/NNN, this is totally odd..
The ImpSvNumberformatInfo is sane, it just reflects the nonsense fed to it by SbiInstance::PrepareNumberFormatter() ;-)
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1ef2cce787df3d254a78ebdb469fb06668f350f4 Revert "svformatter already accept OUString input", fdo#63306 The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Pending review for 4-0 as https://gerrit.libreoffice.org/3468 and for 4-0-3 as https://gerrit.libreoffice.org/3469
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f2fcd0aac530f0ff217304e1869f33d620087dff&h=libreoffice-4-0 Revert "svformatter already accept OUString input", fdo#63306 It will be available in LibreOffice 4.0.4. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-0-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6d9374ca1555a32b94735fc9f66589340a12407a&h=libreoffice-4-0-3 Revert "svformatter already accept OUString input", fdo#63306 It will be available already in LibreOffice 4.0.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Hi, it works fine, verified with Version 4.0.4.0+ (Build ID: 7ab63a1eff3ca8391dd1974cc0cf2b4c7ebb527) Vista-32b Happy to see it will be available on next 4.0.3 Thanks
It works fine, verified with Version 4.0.4.0+ (Build ID: 7ab63a1eff3ca8391dd1974cc0cf2b4c7ebb527) Win7-64b Thanks
*** Bug 64408 has been marked as a duplicate of this bug. ***