Tables in Writer can do automatic "number recognition" [1], [2]. However, it's not easily discoverable in help by users (see tdf#138378): e.g., the term "Number Recognition" is not something that users would enter into search box when they need to disable date automatic conversion. Additionally, [1] mentions the context menu entry that was removed from context menu, and doesn't mention that it's available in main menu (Table->Number Recognition; mentioned in tdf#137084). So [1] needs to be updated with correct menu access; and it needs to get more search terms to be discoverable. [1] https://help.libreoffice.org/7.0/en-US/text/swriter/guide/number_date_conv.html [2] https://help.libreoffice.org/7.0/en-US/text/shared/optionen/01040500.html
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/c2146f0ddc2dff0b5b4b3bb488ecb98513984b64 tdf#138389 update Number Recognition help and improve indexing
cc: Eike Rathke, with hopes for some insight.... According to: https://help.libreoffice.org/7.1/en-US/text/swriter/guide/number_date_conv.html "LibreOffice can automatically format dates that you have entered into a table, according to the regional settings specified in your operating system." 4 questions 1. Is this true? 2. Shouldn't it say: according to the locale setting that you set in Tools>Options>Language Settings>Language - Locale setting 3. Can the formatting of the locale be modified? (or does the locale setting determined a fixed formatting?) 4. "Date acceptance patterns" can be used to "tune" what is recognized as a date in a table cell, independently of and in addition to the locale setting? Answers to these all seem worth mentioning on the Number Recognition help page, which I am willing to do -- if I can get accurate information.
(In reply to sdc.blanco from comment #2) > 1. Is this true? It depends.. > 2. Shouldn't it say: according to the locale setting that you set in > Tools>Options>Language Settings>Language - Locale setting Yes, but ... if the locale is set to "Default - [whatever]" it follows the system locale. If you change the system locale (or LC_CTYPE on Linux) and start LibreOffice then another locale is used. So we maybe should rather say "the LibreOffice locale" (not to be confused with the UI language/locale) and somewhere explain the chain of default locales, as 1. System locale 2. LibreOffice locale (if Default then the System locale, else the locale set) 3. (only in Calc) the cell's number format locale (if Default then LibreOffice locale, else the locale set) > 3. Can the formatting of the locale be modified? (or does the locale > setting determined a fixed formatting?) The default date and date+time formats of a locale are fixed. > 4. "Date acceptance patterns" can be used to "tune" what is recognized as a > date in a table cell, independently of and in addition to the locale setting? Yes.
@Eike - many thanks for explanations - very helpful. @Mike -- maybe this bug should be reopened (or we can leave it closed and I will finish the work now). Note that: https://help.libreoffice.org/7.0/en-US/text/swriter/guide/number_date_conv.html only referred to "date" and the patch (in comment 1) continued along those lines. https://help.libreoffice.org/7.1/en-US/text/swriter/guide/number_date_conv.html But that page needs to be generalized to indicate that all kinds of numbers can be formatted, as explained at: https://help.libreoffice.org/7.0/en-US/text/shared/optionen/01040500.html Meanwhile, that page (which is for Tools>Options>LibreWriter>Table) does not seem like the right place for explaining about Number Recognition in Tables (in general) Are these two pages that you identified the only help pages that discuss "Number Recognition in Tables"? Will have to think about whether to include the information about "Date" that Eike has provided.
@Eike - an additional question that has come up about another sentence in the help page about "Date Acceptance Patterns" Here is the sentence: "In addition to the patterns defined in the edit box, input matching the Y-M-D pattern is also recognized and converted automatically to a date, and since %PRODUCTNAME 3.5 is formatted as YYYY-MM-DD (ISO 8601)." (where "edit box" refers to the place in the dialog where a user can enter these patterns.) 1. Does this sentence accurately reflect the intended LO implementation? 2. IIUC, if Number Recognition is enabled and 3-4-5 , for example, is entered into a Writer table cell, then this input should be converted to Date (and formatted according to ISO 8061). If I use a locale setting that already has Y-M-D as a pattern, then it works as stated, but when I tried with French (Switzerland) locale, which does not use "-" in its default patterns, then it was not recognized. Cannot interpret whether that is expected behavior or bug.
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/ac90f2c26437ee2a8710531d73a9fcd4b31f346b tdf#138389 improve the "guide" page for number recognition in Writer tables
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/6e7f4ece270fd504303ab279795462ce22c3de27 tdf#138389 update help for Options>Language Settings>Languages, especially Date Acceptance Patterns
(In reply to sdc.blanco from comment #5) > "In addition to the patterns defined in the edit box, input matching the > Y-M-D pattern is also recognized and converted automatically to a date, and > since %PRODUCTNAME 3.5 is formatted as YYYY-MM-DD (ISO 8601)." > > 1. Does this sentence accurately reflect the intended LO implementation? Yes. > 2. IIUC, if Number Recognition is enabled and 3-4-5 , for example, is > entered into a Writer table cell, then this input should be converted to > Date (and formatted according to ISO 8061). Why should 3-4-5 be an ISO date? It's an ambiguous sequence. 2003-04-05 is a date (and 2003-4-5 is also recognized). To enter a year 3 (not 2003) at least three digits are needed for year, like 003-04-05 or 0003-04-05. > If I use a locale setting that already has Y-M-D as a pattern, then it works > as stated, Because then it matches the locale's pattern, not the overall ISO 8601 criteria.
Thanks Eike -- this is very helpful. Everything is clear to me now (and also works empirically in my different tests). I agree about the ambiguity of 3-4-5. In an earlier patchset (on the way to the submitted patch), I tried to express the idea that the Y in the Y-M-D had to be a full year -- but my formulation was not adequate. But now I am going to try again... @Mike -- maybe a clause should be added to that correct sentence? (it is put in parentheses, only to show what has changed) In addition to the patterns defined in the edit box, input matching the Y-M-D pattern is also recognized and converted automatically to a date, (where Y must be the full year.) Since %PRODUCTNAME 3.5, this input is formatted as YYYY-MM-DD (ISO 8601).
(In reply to sdc.blanco from comment #9) > In addition to the patterns defined in the edit box, input matching the > Y-M-D pattern is also recognized and converted automatically to a date, > (where Y must be the full year.) Since %PRODUCTNAME 3.5, this input is > formatted as YYYY-MM-DD (ISO 8601). No. You repeat it again, and it's not true: the year has not be full*, it only has to be *unambiguous*. 0 (one digit zero) is accepted, and converted to 2000 - so year needs not to be full. 32 (thirty two) gets accepted as 1932. It is likely that explicitly 1 to 31 are not accepted as Y in implicit Y-M-D - to not interfere with *possible* D-M-Y or something like that.
(In reply to Mike Kaganski from comment #10) > No. You repeat it again, and it's not true: the year has not be full*, it > only has to be *unambiguous*. I have understood this point. But sometimes trying to explain all details clearly makes for more confusion. It is not FALSE to use full year -- and from a practical point of view, it gives a reliable result. > 32 (thirty two) gets accepted as 1932. So why isn't 432 accepted as 1432? (-: Or 032 accepted as 1032? ( iow, there is a friendly assist with 32-99 -- which -- if you knew about this -- then '32' would not "ambiguous" -- but "to be consistent" -- then 032 should be rejected (not converted) as ambiguous (-: ) But look, I am not complaining about the implementation or how to define ambiguous in this context. I only note that you were confused at one point about how this worked, and that what is currently written could probably be improved (to give the innocent user some hints about years). The following, I believe is exhaustive and accurate, but not an improvement (for the average Benjamin user). In addition to the patterns defined in the edit box, input matching the Y-M-D pattern is also recognized and converted automatically to a date, where 32-99 gets 19 added automatically in front, 0 becomes 2000, otherwise the precise year must be entered. Here is a version that only skips 0, but is it better than saying nothing? or suggesting "full year"? In addition to the patterns defined in the edit box, input matching the Y-M-D pattern is also recognized and converted automatically to a date, where 32-99 is recognized automatically as having 19 in front, otherwise enter the precise year. @Mike - your call. I am not trying to sell anything. You are the OP. I am just trying to see if an improvement could be made before closing the door on the help page. If you are happy with the current version, then that was that.
(In reply to sdc.blanco from comment #11) Well, please don't use the "You are the OP" when we discuss what was not covered by this issue as I had filed it ;-D I explicitly stated the issues that I saw, and the improvement (I mean that!) that you are adding now, and that we are discussing in the last comments, is good but not covered by the report :-) I don't believe that trying to "improve" by stating what may be easily disproved is an improvement. Given your proposal, a user would assume that either (a) only 4-digit numbers must be accepted (and then stuff like 0-x-x, 32-x-x, and 123-x-x would be considered a bug!), or that simply what is put there as the first part will be considered the full year (so 32-x-x would be expected to become 32 AD => treating it as 1932 is a bug; and failure to process 31-x-x as 31 AD is a different bug!) So no, that is a bad change. I would like something like: > In addition to the patterns defined in the edit box, input matching the > Y-M-D pattern is also recognized and converted automatically to a date, > (where Y cannot be from 1 to 31). Since %PRODUCTNAME 3.5, this input is > formatted as YYYY-MM-DD (ISO 8601). It would cover it correctly. It would not imply false expectations/interpretations. It doesn't imply that all the range is treated as full year; it explicitly tells that failure for a range is expected. If someone doesn't see a reason in the exclusion, that's a different story, and help is not a place for all the details behind the decisions, but at least it should be correct in what it states.
(In reply to sdc.blanco from comment #11) > where 32-99 gets 19 added automatically in front That's even wrong because how a two-digit input is interpreted depends on the setting under Tools -> Options -> General, Year (Two Digits)
(In reply to Eike Rathke from comment #13) > (In reply to sdc.blanco from comment #11) > > where 32-99 gets 19 added automatically in front > That's even wrong because how a two-digit input is interpreted depends on > the setting under Tools -> Options -> General, Year (Two Digits) Cool. New attempt: In addition to the patterns defined in the edit box, input matching the Y-M-D pattern is also recognized and converted automatically to a date. Two-digit years are interpreted according to the setting in Tools - Options - General - Year (Two Digits). Input that starts from 1 to 31 is not interpreted with the Y-M-D pattern. Since %PRODUCTNAME 3.5, this input is formatted as YYYY-MM-DD (ISO 8601).
*** Bug 138608 has been marked as a duplicate of this bug. ***
(In reply to sdc.blanco from comment #14) > In addition to the patterns defined in the edit box, input matching the > Y-M-D pattern is also recognized and converted automatically to a date. > Two-digit years are interpreted according to the setting in Tools - Options > - General - Year (Two Digits). Input that starts from 1 to 31 is not > interpreted with the Y-M-D pattern. Since %PRODUCTNAME 3.5, this input is > formatted as YYYY-MM-DD (ISO 8601). IMO, the mention of two-digit-year setting here is redundant, and partially misleading. The two-digit-year setting applies to years entered at any place, including those matching explicit acceptance pattern. So explicitly mentioning it here, but not elsewhere on this page where year entry is discussed, may make user think that the two-digit-year setting is exclusively for this implicit Y-M-D input. If wanted, add a link to https://help.libreoffice.org/7.1/en-US/text/scalc/guide/year2000.html at the bottom of the page, in See Also section.
In addition to the patterns defined in the edit box, input matching the Y-M-D pattern is also recognized and converted automatically to a date. Input that starts from 1 to 31 is not interpreted with the Y-M-D pattern. Since %PRODUCTNAME 3.5, this input is formatted as YYYY-MM-DD (ISO 8601). For all patterns, two-digit year input is interpreted according to the setting in <link>Tools - Options - General - Year (Two Digits)</link>. link = https://help.libreoffice.org/7.2/en-US/text/shared/optionen/01010600.html
(In reply to sdc.blanco from comment #17) > In addition to the patterns defined in the edit box, input matching the > Y-M-D pattern is also recognized and converted automatically to a date. > Input that starts from 1 to 31 is not interpreted with the Y-M-D pattern. > Since %PRODUCTNAME 3.5, this input is formatted as YYYY-MM-DD (ISO 8601). > > For all patterns, two-digit year input is interpreted according to the > setting in <link>Tools - Options - General - Year (Two Digits)</link>. Looks good. The only thing that I would change here is replacing > Input that starts from 1 to 31 is not interpreted with the Y-M-D pattern with > Input that starts from 1 to 31 is not interpreted with this implicit pattern because repeating the Y-M-D here is a bit vague, allowing the false interpretation "*any* Y-M-D, including manually entered in the patterns box, not only this implicit one".
In addition to the explicit patterns defined in the edit box, input matching the Y-M-D pattern is implicitly recognized and converted automatically to a date. Input that starts from 1 to 31 is not interpreted with this implicit Y-M-D pattern. Since %PRODUCTNAME 3.5, this input is formatted as YYYY-MM-DD (ISO 8601). ( #making the meaning of "implicit" more "explicit" (-: )
(In reply to sdc.blanco from comment #19) LGTM :-)
Seth Chaiklin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/256943b5885310416bf7422e132dc94ce1d78f7f tdf#138389 improve Y-M-D pattern and add two-digit year explanation
Thanks for input Eike. Thanks for debate Mike. (-: Closing the door on this already resolved bug report. I hope some unknown OP is happy. (-: