Bug 52240 - [Task] EDITING: Incomplete Date values are no longer detected
Summary: [Task] EDITING: Incomplete Date values are no longer detected
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.0.1 rc
Hardware: x86-64 (AMD64) All
: medium major
Assignee: Eike Rathke
URL:
Whiteboard: target:3.7.0 target:3.6.1 target:4.0....
Keywords:
: 52317 53308 53620 (view as bug list)
Depends on: 52137 52288 53308 53498 53620
Blocks: mab3.6 54336 55909
  Show dependency treegraph
 
Reported: 2012-07-18 17:25 UTC by Johannes Weberhofer
Modified: 2013-06-21 16:57 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
Test date input (8.84 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-07-19 07:31 UTC, Johannes Weberhofer
Details
locale list including inherited patterns (2.13 KB, text/plain;charset=utf-8)
2012-07-20 21:23 UTC, Eike Rathke
Details
new list including also inherited without patterns (2.37 KB, text/plain;charset=utf-8)
2012-07-20 23:05 UTC, Eike Rathke
Details
updated list of locales with w/o patterns (6.91 KB, text/plain;charset=utf-8)
2012-07-27 10:45 UTC, Eike Rathke
Details
Test Kit (262.33 KB, application/x-7z-compressed)
2012-09-01 08:54 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes Weberhofer 2012-07-18 17:25:13 UTC
Before 3.6, the following input was recognized and converted as date (tested with locale de_AT):

1-7 --> 1.7.2012
1-7-12 --> 1.7.2012
1.7 --> 1.7.2012
1.7.12 --> 1.7.2012

This behaviour is no longer present. It's now necessary to enter "1.7.2012" all the time, which takes a long time when you have large tables to edit...
Comment 1 Rainer Bielefeld Retired 2012-07-18 17:45:27 UTC
I know some changes what reduces date recognition from "Bug 49289 - FORMATTING: Automatic date recognition and conversion partially broken, input result is text", but I did not see that in such an extreme way as reporter does

@Johannes Weberhofer
Please contribute a sample document with 2 columns text fomatted and a third one for our own experiments:

reporter's Input      reporter's result    Test here
Comment 2 Johannes Weberhofer 2012-07-19 07:31:11 UTC
Created attachment 64374 [details]
Test date input

A de-locale should be used to test that document, as other language's date formates are different.

For German keyboard-layouts it's important to support the "-" sign as date seperator because the dot, which is normally used for date seperation, is not available at the numerical keyboard.
Comment 3 Johannes Weberhofer 2012-07-19 15:13:11 UTC
I have recognized, that "19-7-12" will be replaced by "12.7.2019" instead of "19.7.2012"...
Comment 4 Rainer Bielefeld Retired 2012-07-19 19:10:15 UTC
<https://wiki.documentfoundation.org/BugTriage#Process>  item 5

Results of a first quick test:
Currently I can't see anything what I would really call a bug. But the interpreter is very picky: for formatting '"YYYY-MM-DD" an input "MM-DD" will not be accepted. That might be correct, I am not sure whether "MM-DD" is a date confirming to German standards (I used German loc. for that test).

Exactly following the selected date formatting with the input will be accepted as a date. 

We will have to distinguish:
a) does the date recognition work correct? My quick test seems to say "yes",
   I did not find a real "bug"
b) is that already optimum useful? I do not thing so. A cell formatted "YY-MM-DD"
   should accept an input "12-31" and complete it to date "12-12-31"

@Eike:
Is there already a test proceeding for such us-advise fine tuning? If not, we will have to create sample documents (for all localizations) with examples where practical work might need exceptions from total correctness in favor of usability?
Comment 5 Johannes Weberhofer 2012-07-19 19:53:24 UTC
There are three reasons, why entering "day-month" and "day-month-year" variants of dates should be possible:

* Compatibility:
This behaviour worked as I described with MS-Ecxel 4+, MS-Access 95+, Staroffice, Openoffice and Libreoffice. So power-users expect that behaviour.

* Usability: 
there is no "." awaylable at the numerical keyboard. So whenever you have to enter dates, you must use the "." from the textual keyboards - this is _very_ time-consuming.

* Speed:
A typical buisiness-spreadsheet-user who does e.g. some accounting, is using dates within the same year (older/newer dates are the exceptions). So speeds up input, when you can enter DAY-MONTH and the processor converts it into a date within the same year using the default locale's date-format.


I have never tried with other locales, but I would expect the following behaviour:

A) User enters NUM-NUM: Input processor tries to match the locale's default date format without years. When ok, the current year should be added and the cell should be filled with a date having the standard date format.

B) User enters NUM-NUM-NUM: Input processor tries to match the locale's default date format. When ok, the cell should be filled with a date having the standard date format.

I do not know, if it was possible to enter "DD-MM HH:MM" before. I do currently not have access to an older version.
Comment 6 Rainer Bielefeld Retired 2012-07-20 05:36:11 UTC
We sill have to treat different cases in different bugs, this one will stay as Task Bug.

For everything we do ISO should be considered (bug not be followed slavish): <http://www.probabilityof.com/iso/8601v2000.pdf>

@Johannes Weberhofer:
I agree with some of your arguments, with some I do not. 

* Compatibility  (objected)
May be some power coach drivers will want a horsewhip instead of an accelerator pedal in their cars, but of course, it is improbable that any car manufacturer will fulfill that request

* Usability   (agreed)
Yes, of course. I have been used to input dates many only by numerical keyboard (and I it's horrible that I did not find a way to input a particular day of the month without moth input from numerical keyboard).
In a cell with date formatting any valid date input for the current localization has to be accepted and to be transformed to date view in accordance to 
But: There is no need to accept invalid inputs. This only destroys unambiguity of inputs.
I submitted "Bug 52288 - [DE] EDITING: Allow truncated date inputs from numeric keyboard" for this particular problem, may be additional bugs for additional localizations should be submitted.

More comments following soon.
Comment 7 Eike Rathke 2012-07-20 15:20:59 UTC
(In reply to comment #0)
> 1-7 --> 1.7.2012
> 1-7-12 --> 1.7.2012
> 1.7 --> 1.7.2012
> 1.7.12 --> 1.7.2012
> 
> This behaviour is no longer present. It's now necessary to enter "1.7.2012" all
> the time, which takes a long time when you have large tables to edit...

Indeed we missed to add a date acceptance pattern for de_AT abbreviated dates. However, I think that then should be D.M. and not D.M (note the trailing dot difference), people from German language regions actually were complaining about the recognition of 1.7 as date instead of string, e.g. as in a numbering, therefor input of 1.7. would be necessary for date recognition.

For 1-7 case it's similar, it may easily get in your way.

For 1-7-12 there's the dreaded interference with ISO 8601 abbreviated dates (though we could say that for these the year has to be >31, but will users understand that?)

Btw, 1.7.12 _is_ accepted and leads to 1.7.2012
Comment 8 Eike Rathke 2012-07-20 15:49:40 UTC
(In reply to comment #4)
> b) is that already optimum useful? I do not thing so. A cell formatted
> "YY-MM-DD"
>    should accept an input "12-31" and complete it to date "12-12-31"

And there the corner cases start. If we implemented date input according to the output (!) format I'd hand you an empty form with differently formatted date fields and asked you to fill all in with a certain date. My bet is you'd not even get 50% right at the first try and pay me 100Euro for each failure ;-)

> @Eike:
> Is there already a test proceeding for such us-advise fine tuning? If not, we
> will have to create sample documents (for all localizations) with examples
> where practical work might need exceptions from total correctness in favor of
> usability?

Documents aren't needed, help of all (!) l10n teams would be sufficient. Back when I introduced the patterns I asked on the l10n mailing list (feedback was good but not sufficient) and wrote 2 blog posts and pointed to those also in the release notes, asking for patterns. I can just repeat here what we currently have in 3.6.0, what isn't covered yet we'll have either to guess or to discover through user reports:

Locales with explicit DateAcceptancePattern elements:
an_ES:
    D/M
be_BY:
    D/M/
    D.M.
bg_BG:
    D.M.Y г.
    D.M.Y г.
    D.M.Y Г.
    D.M.Y Г.
br_FR:
    D/M
    D.M.Y
    D-M-Y
ca_ES:
    D/M
cs_CZ:
    D.M.
    D. M.
    D. M. Y
    D. M.
    D. M. Y
de_DE:
    D.M.
en_GB:
    D/M
    D-M
en_US:
    M/D
es_ES:
    D/M
et_EE:
    D.M
    D. M
    D.M.
    D. M.
fi_FI:
    D.M.
fr_BE:
    D/M
fr_CH:
    D/M
    D.M.
fr_FR:
    D/M
    D.M.Y
    D-M-Y
fr_LU:
    D/M
gd_GB:
    D/M
    D-M
gsc_FR:
    D/M
    D.M.Y
    D-M-Y
is_IS:
    D.M.
    D. M.
    D. M. Y
    D/M/
it_IT:
    D/M
ja_JP:
    M-D
    M/D
    M/D
    Y.M.D
    Y/M/D
    Y年M月D日
    M月D日
kab_DZ:
    D/M
lt_LT:
    M-D
nl_BE:
    D/M
nl_NL:
    D-M
oc_FR:
    D/M
    D.M.Y
    D-M-Y
pt_AO:
    D-M
pt_BR:
    D/M
pt_PT:
    D-M
ru_RU:
    D.M.
    D/M/
sk_SK:
    D.M.
    D. M.
    D. M. Y
    D. M.
    D. M. Y
sl_SI:
    D. M. Y
    D.M.
    D. M.
sv_SE:
    D/M
    D/M Y
tr_TR:
    D.M
    D/M
    D-M
zh_CN:
    M-D
    M/D
    M/D
    Y.M.D
    Y/M/D
    Y年M月D日
    M月D日
zh_TW:
    M月D日
    M-D
    M/D
    Y年M月D日
    Y.M.D


Locales without explicit DateAcceptancePattern elements:
(one implicit full date pattern is always generated)
ak_GH
ar_DZ
ar_EG
ar_OM
ast_ES
az_AZ
bn_IN
bs_BA
cv_RU
da_DK
de_AT
de_CH
de_LI
de_LU
dsb_DE
dz_BT
ee_GH
el_GR
en_AU
en_CA
en_GH
en_JM
en_NA
en_ZA
eo
es_AR
es_BO
es_CL
es_CO
es_CR
es_DO
es_EC
es_GT
es_PE
eu
fa_IR
fo_FO
fr_CA
fur_IT
fy_NL
gl_ES
gug_PY
ha_GH
haw_US
he_IL
hi_IN
hil_PH
hr_HR
hsb_DE
ht_HT
hu_HU
hy_AM
ia
id_ID
it_CH
jbo
ka_GE
kk_KZ
kl_GL
km_KH
ko_KR
ku_TR
ky_KG
la_VA
lb_LU
lg_UG
lif_NP
ln_CD
lo_LA
ltg_LV
lv_LV
mai_IN
mk_MK
ml_IN
mn_MN
mt_MT
my_MM
myv_RU
ne_NP
no_NO
om_ET
or_IN
pjt_AU
pl_PL
plt_MG
ro_RO
rue_SK
rw_RW
sc_IT
sg_CF
shs_CA
so_SO
sr_RS
sv_FI
sw_TZ
tg_TJ
th_TH
ti_ER
tk_TM
tpi_PG
ug_CN
uk_UA
ur_PK
uz_UZ
vi_VN
wa_BE
zh_HK
zh_MO
zh_SG
Comment 9 Not Assigned 2012-07-20 15:53:14 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d0d840c27943f976fd59a673f2de84a10ea475c9

fdo#52240 added abbreviated date acceptance patterns for [de-{AT,CH,LI,LU}]
Comment 10 Not Assigned 2012-07-20 16:27:48 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=41306f222d7f3aa3fedcd2a9a91fd7558449a24e&g=libreoffice-3-6

fdo#52240 added abbreviated date acceptance patterns for [de-{AT,CH,LI,LU}]


It will be available in LibreOffice 3.6.1.
Comment 11 Johannes Weberhofer 2012-07-20 17:54:18 UTC
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
Comment 12 Alex Thurgood 2012-07-20 18:29:43 UTC
*** Bug 52317 has been marked as a duplicate of this bug. ***
Comment 13 Eike Rathke 2012-07-20 20:15:48 UTC
(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.
Comment 14 Eike Rathke 2012-07-20 21:23:07 UTC
Created attachment 64467 [details]
locale list including inherited patterns

The previous list of locales was slightly incomplete as it didn't include locales that inherit their patterns from other locales. Attaching the full list here.
Comment 15 Eike Rathke 2012-07-20 23:05:19 UTC
Created attachment 64471 [details]
new list including also inherited without patterns

Previous lists omitted inherited locales that do not inherit patterns. This list should be complete now.
Comment 16 Not Assigned 2012-07-23 11:36:58 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-3-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=04f857bc7596ba13cb2dc4a74f77aa1822575f04&g=libreoffice-3-6-0

fdo#52240 added abbreviated date acceptance patterns for [de-{AT,CH,LI,LU}]


It will be available already in LibreOffice 3.6.0.
Comment 17 Eike Rathke 2012-07-25 17:43:37 UTC
I committed these to master
http://cgit.freedesktop.org/libreoffice/core/commit/?id=7828847618b58ff2009b5ce55416a8b2e5dcf55a
http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae660e9efa4994bbfafa6de46b4b18aef2f1bb49
http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc52902eb218095652bf2921d5acfb9d0c863ac9
http://cgit.freedesktop.org/libreoffice/core/commit/?id=05035c894644f700fdc972b51dbd918f7530b2d5

They add an abbreviated date acceptance pattern to locales that have a '/' date separator where M/D and D/M are uncontroversial.

Asked for review to get this into 3-6, so it hopefully will be in 3.6.1
Comment 18 Not Assigned 2012-07-25 17:50:19 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7828847618b58ff2009b5ce55416a8b2e5dcf55a

fdo#52240 added M/D date acceptance pattern to locales with Y/M/D edit format
Comment 19 Not Assigned 2012-07-25 17:50:44 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae660e9efa4994bbfafa6de46b4b18aef2f1bb49

fdo#52240 added M/D date acceptance pattern to locales with Y/M/D edit format
Comment 20 Not Assigned 2012-07-25 17:51:10 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=dc52902eb218095652bf2921d5acfb9d0c863ac9

fdo#52240 added D/M date acceptance pattern to locales with D/M/Y edit format
Comment 21 Not Assigned 2012-07-25 17:51:35 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=05035c894644f700fdc972b51dbd918f7530b2d5

fdo#52240 added M/D date acceptance pattern to locales with M/D/Y edit format
Comment 22 Not Assigned 2012-07-26 07:54:21 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f083b08b9b77f24d62644d7bcd6bf97c8a7712ed&g=libreoffice-3-6

fdo#52240 added M/D date acceptance pattern to locales with Y/M/D edit format


It will be available in LibreOffice 3.6.1.
Comment 23 Not Assigned 2012-07-26 07:54:51 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7356e71517592cb91fc47f9304e074050b493b49&g=libreoffice-3-6

fdo#52240 added M/D date acceptance pattern to locales with Y/M/D edit format


It will be available in LibreOffice 3.6.1.
Comment 24 Not Assigned 2012-07-26 07:55:21 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=aa5dac69f419b1c190b62058930e576fdf4489d7&g=libreoffice-3-6

fdo#52240 added D/M date acceptance pattern to locales with D/M/Y edit format


It will be available in LibreOffice 3.6.1.
Comment 25 Not Assigned 2012-07-26 07:55:52 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=a10f7178b3b57eb81bc5d3ef046bfc935e8ba346&g=libreoffice-3-6

fdo#52240 added M/D date acceptance pattern to locales with M/D/Y edit format


It will be available in LibreOffice 3.6.1.
Comment 26 Eike Rathke 2012-07-27 10:45:22 UTC
Created attachment 64770 [details]
updated list of locales with w/o patterns

This is what currently is in master and will be in 3.6.1; lists also date separator used and edit format for each locale.
Comment 27 Mikeyy - L10n HR 2012-08-01 05:33:40 UTC
Just wanted to report this, but I noticed someone was quicker.
Tested on 3.6.0.4 and on hr locale if I enter 31.7 date isn't automaticaly filled even with cell formatting set to dates.
Not sure why old behaviour was tampered with and changed when it was good.
Comment 28 Johannes Weberhofer 2012-08-01 06:41:03 UTC
Please bring back the old behaviour! I have tested the latest RC, but there is still no possibility to enter the date with the numerical keyboard in the german region.

Is there really a need for breaking compatibility with things working for ~20 years now when it makes things worse?
Comment 29 Kriton Kyrimis 2012-08-01 07:03:19 UTC
(In reply to comment #27)
> Tested on 3.6.0.4 and on hr locale if I enter 31.7 date isn't automaticaly
> filled even with cell formatting set to dates.

Same here. Greek (el) locale, Windows XP. Fails on "31/7".
Comment 30 Midiar 2012-08-16 21:43:49 UTC
(In reply to comment #27)
Tested on LibO_3.6.1.1_MacOS_x86_install_en-US.dmg and LibO_3.6.1.1_MacOS_x86_langpack_nb.dmg

Setting 31.12.1999 as the date format for a cell, and then inputting 16.8, it is not displayed as 16.8.2012, which it did before (LibreOffice 3.5.5).

This is breaking some useful and sensible data entry compatibility, and it should be unnecessary (since the cell's date format is known).
(I even think I remember this happened some time ago in another 3.x.0 release, before it got fixed.)
Comment 31 Mikeyy - L10n HR 2012-08-28 09:32:08 UTC
According to bug 52288 comment #11: https://bugs.freedesktop.org/show_bug.cgi?id=52288#c11
I'm asking for inclusion of
31.08
31.8
31.08.
31.8.
31.08.12
31.8.12

and same variants with / and - as an separator to be included in date recognition when cells are default formatted (number/general) for Croatian locale (could be same for other locales, not sure).

In Croatia we use comma , as decimal separator so you can recognise . without problems as date entry, not numeric entry.

If you will force date recognition on date formatted cells, you can even recognise comma as date separator, but only on date formatted cells.
Comment 32 Eike Rathke 2012-08-28 11:29:41 UTC
(In reply to comment #31)
> I'm asking for inclusion of
> 31.08
> 31.8
> 31.08.
> 31.8.

These are all the same pattern D.M that can easily be added to locale data.

> 31.08.12
> 31.8.12

These are full dates, just with 2-digit year, and covered by the automatic D.M.Y full date pattern, input is already possible.


> and same variants with / and - as an separator to be included in date
> recognition when cells are default formatted (number/general) for Croatian
> locale (could be same for other locales, not sure).

This exactly is not wanted. People were complaining that too many input patterns were converted to date even if the input did not resemble a date in the selected locale, which is why the new behavior was implemented. In future releases the date acceptance patterns will be editable to suit everyone's needs.
Comment 33 Not Assigned 2012-08-28 11:41:32 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c2b40d6fa57e0176d52ec4ac0565de352064c661

fdo#52240 added D.M date acceptance pattern to [hr-HR]
Comment 34 Johannes Weberhofer 2012-08-28 12:15:50 UTC
(In reply to comment #32)
> (In reply to comment #31)
> > and same variants with / and - as an separator to be included in date
> > recognition when cells are default formatted (number/general) for Croatian
> > locale (could be same for other locales, not sure).
> 
> This exactly is not wanted. People were complaining that too many input
> patterns were converted to date even if the input did not resemble a date in
> the selected locale, which is why the new behavior was implemented. In future
> releases the date acceptance patterns will be editable to suit everyone's
> needs.

There are also many people who want to be the - (and possibly /) signs be recognized for date input.

Try to enter a list of 50 lines having dates with a german keyboard: In the new variant you always have to move between the numerical and the textual parts of the keyboard or use both hands for typing the values. In both cases you do not have your other hand free for following the line at the paper, and you have always to watch the keyboard to see if you reached the . sign which is the date seperator.

You refer to people which were complaining about input patterns: Is there any reference?
Comment 35 Johannes Weberhofer 2012-08-28 12:19:10 UTC
Could a option be added, which allows "enhanced date recognition" or something like that when the old behaviour can not be restored?

For me and some customers this new feature is really bad. Especially when people where used to that behaviour since 20 years...
Comment 36 Mikeyy - L10n HR 2012-08-28 20:09:16 UTC
> > 31.08.12
> > 31.8.12
>
> These are full dates, just with 2-digit year, and covered by the automatic
> D.M.Y full date pattern, input is already possible.

Yes, but those full dates (31.08.12) didn't work in 3.6, that's why I'm reporting it here.

> > and same variants with / and - as an separator to be included in date
> > recognition when cells are default formatted (number/general) for Croatian
> > locale (could be same for other locales, not sure).
>
> This exactly is not wanted. People were complaining that too many input
> patterns were converted to date even if the input did not resemble a date in
> the selected locale, which is why the new behavior was implemented. In future
> releases the date acceptance patterns will be editable to suit everyone's
> needs.

Who complained? Where?
I have a feeling that 0,5% of 10.000.000 user base complained and now other 99,5% will suffer.
Are there any examples of numbers using - or / which can be mistaken for dates?
I can only think of one, invoice numbers which usually looks something like:
1234/12
1234/2012
1234-5678-12
...
Comment 37 Eike Rathke 2012-08-29 10:35:38 UTC
PLEASE STOP DISCUSSION, THANK YOU!

I'm working on a solution that enables editing and setting the date acceptance patterns to everyone's like.
Comment 38 Not Assigned 2012-08-29 15:30:14 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9019bbf37b0460407823d98134f87f355af54123&g=libreoffice-3-6

fdo#52240 added D.M date acceptance pattern to [hr-HR]


It will be available in LibreOffice 3.6.2.
Comment 39 Not Assigned 2012-08-29 19:21:25 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cda156257003df673fa853a0a5ffcd1cb4848d43

resolved fdo#52240 fdo#52137 fdo#52288 user editable date patterns
Comment 40 Björn Michaelsen 2012-08-30 17:18:15 UTC
Dear bug reporters,

Eike has suggested this bug to be fixed as a late feature in 3.6 with:

 https://gerrit.libreoffice.org/#/c/511/

to be sure, there are no regression from this, please test a daily build from:

 http://dev-builds.libreoffice.org/daily/

and see if you see any trouble with the fix.
Comment 41 Johannes Weberhofer 2012-08-30 17:52:49 UTC
(In reply to comment #40)

> to be sure, there are no regression from this, please test a daily build from:
>  http://dev-builds.libreoffice.org/daily/
> and see if you see any trouble with the fix.

In "Version 3.6.2.0+ (Build ID: 3f8da6a)" (OSX) this feature is not (yet?) available. I've downloaded from http://dev-builds.libreoffice.org/daily/MacOSX-Intel@3-OSX_10.6.0-gcc_4.0.1/libreoffice-3-6/2012-08-30_03.41.06/
Comment 42 Kriton Kyrimis 2012-08-31 09:17:38 UTC
(In reply to comment #40)

I tried version 2012-08-30_21.52.14, under Windows XP and the Greek (el_GR) locale.

Without playing with the new setting, D/M and D/M/Y are properly recognized as dates, while nothing else is. After adding patterns in the new setting, dates following the added patterns are recognized properly, as well. Anything I could think to add, worked properly. LO could even tell the difference between D.M and D.M. (i.e., the trailing dot), so, as far as I can tell, this feature works as specified, assuming, of course, that nobody uses semicolons as date separators!)

There are three caveats, however:
a) I have been bitten by bug #40359, so I cannot access this setting from either of my computers; I had to test the feature on a third computer.
b) It seems to me that this feature is so hidden, that people will keep submitting bug reports on this issue.
c) In Greece, although / is, apparently, the standard date separator, dashes are also quite common. Out of curiosity, I asked someone at our accounting department, who is obviously a heavier spreadsheet user than myself, if they thought it would be alright if, say, excel stopped recognizing dashes as date separators, replacing the removed functionality with a setting, where they could specify additional separators. Her reply was: "why should I have to do that?"

I think that a good compromise might be to keep this new feature, but use, as the default pattern, a long pattern that would emulate the old behavior. This way, people who want a more restricted set of date patterns to be recognized, can simply delete whatever they do not like, while people who want the old behavior, can have it, without having to figure out which patterns to add.
Comment 43 Kriton Kyrimis 2012-08-31 09:23:57 UTC
> I think that a good compromise might be to keep this new feature, 

Better, yet, replace the new option with three radio buttons:

* Classic
* Locale Dependent
* Advanced _______________

"Classic", which should be the default, should select the long pattern, which should be also filled in the text area in "advanced".
"Locale Dependent" should do the same with the new, shorter pattern.
"Advanced" should let one specify arbitrary patterns, as the new option currently does.
Comment 44 Johannes Weberhofer 2012-08-31 09:50:48 UTC
(In reply to comment #43)
> > I think that a good compromise might be to keep this new feature, 
> 
> Better, yet, replace the new option with three radio buttons:
> 
> * Classic
> * Locale Dependent
> * Advanced _______________
> 
> "Classic", which should be the default, should select the long pattern, which
> should be also filled in the text area in "advanced".
> "Locale Dependent" should do the same with the new, shorter pattern.
> "Advanced" should let one specify arbitrary patterns, as the new option
> currently does.

This would be great! I have suggested something like that in bug #52288

I also think it's problematic when users have suddenly to search for an option to continue working as they did. I think, "locale dependend" could be left out, instead ther should be a (inactive) default value for the advanced option which can easily be adopted.

Erik noted in a comment in https://bugs.freedesktop.org/show_bug.cgi?id=52288#c15, that the defaults are quite complex for the languages...
Comment 45 Kriton Kyrimis 2012-08-31 10:03:39 UTC
> the defaults are
> quite complex for the languages...

Which is why I suggested adding the "locale dependent" option, so that users, who do want the new behavior, don't have to figure out what patterns to specify. The current behavior in 3.7 seems to be a combination of "advanced" (users must specify the date patterns) and "locale dependent" (a set of patterns has already been pre-selected, based on the locale, e.g., "D/M;D/M/Y" for the Greek locale).
Comment 46 Rainer Bielefeld Retired 2012-08-31 15:06:46 UTC
I worked a while with unzipped MinGW Master "3.7.0.0.alpha+ [Build ID: 4deb9d4] English Locale/UI {Win-x86@7-MinGW   pull time 2012-08-31 05:20:19} on WIN7 Home Premium (64bit) ,tried alternative "M-D;D.M.", works great
Comment 47 Rainer Bielefeld Retired 2012-08-31 19:14:23 UTC
"Bug 54336 - EDITING: Input in a timestamp-field only with completed date-input possible" is concerning the problem that until LibO 3.5 a date input 
DD.MM hh:mm   (German Locale: 31.12. 23:49) was recognized as Date + Time. Unzipped MinGW Master "3.7.0.0.alpha+ [Build ID: 4deb9d4] English Locale/UI {Win-x86@7-MinGW   pull time 2012-08-31 05:20:19} on WIN7 Home Premium (64bit) cnant# t handle that, at least I found no setting for Date input. 

It would be great if that pattern concept could be enhanced for that.
Comment 48 Eike Rathke 2012-08-31 22:11:50 UTC
(In reply to comment #47)
I don't quite understand. The build you used does include the new editable date acceptance patterns, yes? To be able to enter 31.12. 23:49 you need a D.M. pattern, for 31.12 23:49 you need a D.M pattern, note difference in trailing dot. You can add both in the options dialog.
Comment 49 Rainer Bielefeld Retired 2012-09-01 07:19:13 UTC
> The build you used does include the new editable date acceptance patterns, yes?

Yes

> To be able to enter 31.12. 23:49 you need a D.M.
> pattern, for 31.12 23:49 you need a D.M pattern, note difference in trailing
> dot. 

Of course I noted that. I found no way that LibO accepted input  "31.12 23:49" as Date-Time.

I would have liked to attach a spreadsheet with my results showing them more clearly, but save is broken there :-(

So here a copy/paste

Result for input        Original Input as Text	
------------------------------------------------------
2012-12-31 00:00:00     31.12.	
2012-12-31 00:00:00     31.12	
31.12.18:00             31.12. 18:00 Valid usual input should have been 
                                      recognized
2012-12-31 00:00:00     31.12.12	
2012-12-31 18:00:00     31.12.12 18:00	
31.12 18:00             31.12 18:00 Possibility for an enhancement 
                                    with date-time-pattern acceptance
			
I will install a new Master today where save should work, if it helps, Of course I can attach a spreadsheet with my test results.
Comment 50 Rainer Bielefeld Retired 2012-09-01 08:05:19 UTC
@Eike:
Crazy, but true: There is a bug only in MinGW wo that example "31.12 23:49" is not recognized in that build.

Works fine with parallel installation of Master "LOdev  3.7.0.0.alpha0+   -  ENGLISH UI [Build ID: 9bb30a4]"  {tinderbox: 2008R2@20, pull time 2012-08-30 23:44:35} Acceptance pattern=D.M.Y;D.M.;D.M, Locale=German on German WIN7 Home Premium (64bit)

Please excuse me for the noise.
Comment 51 Rainer Bielefeld Retired 2012-09-01 08:54:38 UTC
Created attachment 66432 [details]
Test Kit

Here no some more complete results with parallel installation of Master "LOdev  3.7.0.0.alpha0+   -  ENGLISH UI / German Locale  [Build ID: 9bb30a4]"  {tinderbox: 2008R2@20, pull time 2012-08-30 23:44:35} on German WIN7 Home Premium (64bit)

Documents should be self explaining, for the broken writer date recognition with ISO Date formatting I will submit a separate bug
Comment 52 Rainer Bielefeld Retired 2012-09-01 10:28:36 UTC
Comment on attachment 66432 [details]
Test Kit

I submitted "Bug 54344 TABLE: Date Number Formatting ISO 8601 with wrong number recognition result, Day becomes Year, Day always 1" for the writer specific recognition bug.
Comment 53 Not Assigned 2012-09-07 10:28:53 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=cfbfa26deb2776e5c07463e59517eaf68c1d5d6d&g=libreoffice-3-6

resolved fdo#52240 fdo#52137 fdo#52288 user editable date patterns


It will be available in LibreOffice 3.6.2.

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.
Comment 54 Mikeyy - L10n HR 2012-09-08 19:21:16 UTC
Where can I see settings for patterns?
I'm searching for it, but can't find.

Default is supporting only 31.8 as date input.
31.8.;31.8.12.;15/8;15/8/12 isn't passing.
Comment 55 Johannes Weberhofer 2012-09-25 07:17:07 UTC
*** Bug 53308 has been marked as a duplicate of this bug. ***
Comment 56 Johannes Weberhofer 2012-09-25 07:18:45 UTC
*** Bug 53620 has been marked as a duplicate of this bug. ***
Comment 57 Midiar 2012-10-11 21:07:18 UTC
Just for the record, inputting 31.8 in LibO_3.6.2_MacOS_x86_install_en-US with LibO_3.6.2_MacOS_x86_langpack_nb still does not produce a cell with a date, which worked in LibO 3.5. (Symptom: The cell content is left-justified, and I can't add 1 to it to get the next date.)
Comment 58 Johannes Weberhofer 2012-10-12 13:56:25 UTC
You must now extend your "date recognition pattern" in the language settings to detect all kind of dates. Unfortunately the "classic" patterns are not the default ones.
Comment 59 Mikeyy - L10n HR 2012-10-12 16:34:03 UTC
Where can I file request to increase pattern for croatian (HR) locale?
I asked that here before, asked in bug 52288, asked on mailing list, but I guess it didn't reach needed persons.

In 3.6.2 default pattern was set as:
D.M.Y;D.M

I would like to increase default pattern to at least this:
D.M.Y;D.M;D/M/Y;D/M

Who do I need to ping for this?
Comment 60 Johannes Weberhofer 2012-10-12 19:59:40 UTC
In my opinion this new option is a step in the right direction, but in total the removal of the old default behaviour is a big step back.
Comment 61 Midiar 2012-10-18 21:54:24 UTC
(In reply to comment #58)
> You must now extend your "date recognition pattern" in the language settings
> to detect all kind of dates. Unfortunately the "classic" patterns are not
> the default ones.

OK, put D.M there, and now it correctly recognises 15.10 and 15.10.2012 as the same date, and formats them as 15.10.2012, as before.

OK, two conflicting needs. Maybe this pattern thing is good, giving us control. I'll accept it, and stop being annoyed :-)
Comment 62 Not Assigned 2012-12-10 14:06:52 UTC
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=cf81e0bcab5910c92291884bcbd8c9cbf1758e5a&g=libreoffice-4-0

fdo#52240 added [no-NO] date acceptance patterns D.M;D/M/Y;D/M;D/M Y


It will be available in LibreOffice 4.0.

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.
Comment 63 Not Assigned 2012-12-10 14:07:19 UTC
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=9cce41e668de5b50e05d762b88f3bbafb3bb641a&g=libreoffice-4-0

fdo#52240 added [hr-HR] date acceptance patterns D/M/Y;D/M


It will be available in LibreOffice 4.0.

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.
Comment 64 Not Assigned 2012-12-10 14:07:46 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=638993d9b80b3793dfd31db0dacba3746ceb98fd

fdo#52240 added [no-NO] date acceptance patterns D.M;D/M/Y;D/M;D/M Y



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.
Comment 65 Not Assigned 2012-12-10 14:08:12 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b1184f8a4e4a3949d38407c5f1d5155c2c2b42d5

fdo#52240 added [hr-HR] date acceptance patterns D/M/Y;D/M



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.
Comment 66 Mikeyy - L10n HR 2012-12-10 14:14:27 UTC
Comment #63 and Comment #65
Full pattern should be:
D.M.Y;D.M;D/M/Y;D/M

Not just: D/M/Y;D/M

D.M.Y;D.M is already default pattern in 3.6, I hope your comment means you just added D/M/Y;D/M on top of old default, not removed old default.
Just making it clear so we aren't confused. :)
Comment 67 Eike Rathke 2012-12-10 15:56:33 UTC
(In reply to comment #66)
> D.M.Y;D.M is already default pattern in 3.6, I hope your comment means you
> just added D/M/Y;D/M on top of old default, not removed old default.
> Just making it clear so we aren't confused. :)

Well, just read the commit message carefully and notice the word "added" ;-)
Comment 68 Not Assigned 2012-12-10 16:45:13 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=12281897cc5fa72357b6bce16d18d0356c7213d5&g=libreoffice-3-6

fdo#52240 added [no-NO] date acceptance patterns D.M;D/M/Y;D/M;D/M Y


It will be available in LibreOffice 3.6.5.

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.
Comment 69 Not Assigned 2012-12-10 16:45:36 UTC
Eike Rathke committed a patch related to this issue.
It has been pushed to "libreoffice-3-6":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=7d311177597d2f7e3bdf19a56b9f862da83588f4&g=libreoffice-3-6

fdo#52240 added [hr-HR] date acceptance patterns D/M/Y;D/M


It will be available in LibreOffice 3.6.5.

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.
Comment 70 Timon 2013-02-28 10:27:10 UTC
In LibreOffice 4.0.1.1 (Build ID: 2c0c17a6e4bee0ee28131ea4bdc47edc700d659) problem is still present.
Comment 71 Mikeyy - L10n HR 2013-02-28 10:34:09 UTC
It's working without problems on HR locale.
Comment 72 Michael Meeks 2013-06-12 11:02:27 UTC
Eike - is this issue closed from your perspective ? I see your several patches for it :-) if so, should we close it (it is a MAB ;-)
Comment 73 libreoffice 2013-06-21 11:37:59 UTC
Can I propose that this date recognition does *not* happen when importing an Excel document? I'm guessing that Excel stores dates in cells marked as numbers[1] (not strings), so this shouldn't be a problem. (And I'm asking because I've been bitten a lot by false conversions lately.)

[1]: http://poi.apache.org/apidocs/org/apache/poi/ss/usermodel/Cell.html#getDateCellValue()
Comment 74 Johannes Weberhofer 2013-06-21 11:44:08 UTC
It's only an input issue.
Comment 75 Eike Rathke 2013-06-21 16:57:30 UTC
Ah yes, we can close this. If a certain locale needs some pattern added we can do that either on the fly or have a separate bug if needed.