https://bugs.freedesktop.org/show_bug.cgi?id=52240
--- Comment #13 from Eike Rathke <[email protected]> 2012-07-20 20:15:48 PDT --- (In reply to comment #11) > This change is a good beginning. I'd like to see that dates are also accepted > without the ending dot: D.M But that is _exactly_ what people complained about, that 1.7 is _not_ a valid date in a German locale and their input when entering this kind of text numbering or 1-7 to indicate a range gets converted to date. > 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 There you already have to distinguish between locales, for DMY or MDY order a trailing separator may be allowed, for YMD order it is not. And always accepting a '-' as separator is also not a solution, as lined out above. > } else { > store the inputted string > } Before that are all the extra cases as you can see in a previous comment where the pattern is not simply D.M.Y (or with just another separator or in another order). An there are also 1-Jul-2012, 1. Juli 2012, ... you see, its not that simple. The final solution probably will have to make the date acceptance patterns editable in the user's configuration. It seems there will never be a "one suits all" programmatic solution. Then you could add D.M and D-M if you don't want these inputs to stay strings. -- 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
