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...
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
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.
I have recognized, that "19-7-12" will be replaced by "12.7.2019" instead of "19.7.2012"...
<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?
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.
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.
(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
(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
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}]
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.
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
*** Bug 52317 has been marked as a duplicate of this bug. ***
(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.
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.
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.
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.
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
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
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
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
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
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.
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.
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.
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.
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.
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.
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?
(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".
(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.)
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.
(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.
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]
(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?
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...
> > 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 ...
PLEASE STOP DISCUSSION, THANK YOU! I'm working on a solution that enables editing and setting the date acceptance patterns to everyone's like.
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.
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
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.
(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/
(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.
> 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.
(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...
> 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).
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
"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.
(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.
> 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.
@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.
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 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.
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.
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.
*** Bug 53308 has been marked as a duplicate of this bug. ***
*** Bug 53620 has been marked as a duplicate of this bug. ***
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.)
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.
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?
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.
(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 :-)
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.
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.
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.
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 #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. :)
(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" ;-)
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.
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.
In LibreOffice 4.0.1.1 (Build ID: 2c0c17a6e4bee0ee28131ea4bdc47edc700d659) problem is still present.
It's working without problems on HR locale.
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 ;-)
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()
It's only an input issue.
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.