https://bugs.freedesktop.org/show_bug.cgi?id=82757
Lionel Elie Mamane <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|[email protected] |[email protected] |desktop.org | --- Comment #3 from Lionel Elie Mamane <[email protected]> --- I tracked down one reason that (in some scenarios) it used to work with older LibreOffice versions but not anymore with newer ones: the string-to-date conversion (parsing) has become stricter, so that it does not allow invalid dates such as "35th day of month" or "14th day of month 18" (in a calendar that has less than 18 months). The situation was that: 1) One parse was done with the format and locale attached to the column in the table. 2) A second parse was done with the default locale, but only to see what type of value came out, the date read from it was thrown out. With previous versions the second parse gave an invalid date, but that was thrown away anyway, while in more recent versions the second parse failed, falling back to passing the string as string (instead of as date) to the database layer, which was parsing the string as ISO format (which led to the corruption... in ISO, 18/12/8 is "8 December 18"). I changed the second parse to use the same locale, which makes much more sense. So with this commit, "it should work again as before". -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
