https://bugs.freedesktop.org/show_bug.cgi?id=52240
--- Comment #11 from Johannes Weberhofer <[email protected]> 2012-07-20 17:54:18 PDT --- This change is a good beginning. I'd like to see that dates are also accepted without the ending dot: D.M This is, what older versions of LO behave and what all Excel products behave like. To destinguish those abbreviated dates seperated with minuses only the last valid definition from ISO 8601:2004 [1] which says YYYY-MM-DD is a valid date could be accepted as ISO-Date. So for Germany we could do the following transformations (where the output format should always use the locales default setting): 20.7 -> 2012-07-20 20.7. -> 2012-07-20 20-7 -> 2012-07-20 20-7- -> "20-7-" (invalid) 20.7.10 -> 2010-07-10 20-7-10 -> 2010-07-10 2010-07-20 -> 2010-07-10 2010.07.20 -> "2010.07.20" (invalid) 20.7.2012 -> 2012-07-20 20.7.12 -> 2012-07-20 This system is consistant and doesn't break anything. >From the programming logic I could imagine the following code could do all the interpretation for all languages: if (Is the input string a ISO 8601:2004 (YYYY-MM-DD) date ) { convert to date. } else if (Is the input string a compete date in the locales format (with YY or YYYY used) { convert to date. } else if (Does the input string contain two numbers seperated by the locale's date seperator or a minus sign? Possibly followed by the same seperator at the end? { use the current year to convert the string to date. month and day must be interpreted in the way that is defined in the locale } else { store the inputted string } [1] http://www.iso.org/iso/catalogue_detail?csnumber=40874 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- 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
