[Libreoffice-bugs] [Bug 52240] [Task] EDITING: Incomplete Date values are no longer detected

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=52240

--- Comment #11 from Johannes Weberhofer <jweberhofer at weberhofer.at> 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.