Problem description: ITALIAN LANGUAGE ONLY. Use complete date format (id. martedì 27 settembre. The date is not accepted and the default date is used. Steps to reproduce: 1. ....use complete date format (martedì 27 settembre 2011) 2. ....select and copy the complete date 3. ....paste the selected date to another date field Current behavior: The last date field doesn't accept the selection and turn to the default date (sabato 30 dicembre 1899). Expected behavior: the pasted date field is the same of the former (martedì 27 settembre 2011). Everything works ok if you try with the other days of the week (lunedì, mercoledì, giovedì venerdì sabato, domenica). Everything works ok if write the date (id. martedì 27 settembre 2011) directly in the field typing using the keyboard.
Please could you attach a test file which the problem? Thank you for your help. JBF
NOT reproducible with "LibreOffice 3.5.0 German UI/ Italian Locale [Build-ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735] on German WIN7 Home Premium (64bit). Copy - paste of date as reported works fine in my sample document with Italian as default language. Indeed, a sample document will be required
Created attachment 57364 [details] create in Base with HSQL (but the problem persist also with MySQL, MariaDB ecc. please, write "martedì 21 febbraio 2012" or another date with "martedì" (italian for Tuesday) in date field 1 and copy it in the date field 2: the output will be the default date "sabato 30 dicembre 1899".
[Reproducible] with reporters sample and "LibreOffice 3.5.0 German UI/Locale [Build-ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735] on German WIN7 Home Premium (64bit) With my own sample I see the Same problelm. Steps to reproduce: 1. open newsamplebase.odb 2. select date field "domenica 01 gennaio 2012" with <control+c> 3. with <tab> go to target field and paste with <control+c> As expected due to column formatting you will see "01/01/12" 4 redo for following rows all works fine, only date containing "martedì" will not be recognized and pasted as "30/12/99" Old problem, also with LibO 3.3.0 Portable and OOo 3.1.1, seems inherited from OOo No idea what I did yesterday where everything seemed to work fine @Vittorio Mandelli: What's your OS? @Lionel: Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.
As explained in more detail below, my head is exploding looking at this code, and not my area, so I'm dumping that bug on Eike. Eike, feel free to reassign to someone else in turn. This bug is not specific to Base. It can be reproduced in Calc in the attached document: - type (or paste) "lunedì 11 aprile 2011" at position B2 or B3: it is properly formatted as a Date, and column C shows the numer of days between that date and today. - type (or paste) "martedì 12 aprile 2011" at position B2 or B3; stays as string, not as date, and column C gives error Don't copy the whole cell from column A to column B, as this will copy the format with it. Either type it manually or copy-paste it e.g. from here (your browser or mail client). Analysis: the root of the problem is that "martedì" starts with "mar" which is the abbreviation for "marzo", and the Date parsing code thus tries to match "tedì 27 settembre 2011" as a date-without-month, which fails because "tedì" is not a Date component. Now, a very dirty and quick fix would be to switch the priority of "recognise month" and "recognise day of week" in function ImpSvNumberInputScan::ScanStartString in svl/source/numbers/zforfind.cxx. It might create the symmetric problem in another language, though (a month is not recognised as such because a prefix of it is a valid day-of-week). I tried preparing a more proper patch, which would be to change GetMonth() (and most of the other callers of StringContains()) to match only a whole word, not a prefix. This is made more complicated by languages that don't separate words by non-letter characters (such as space or punctuation). I abandoned the idea of "quickly" doing that when I realised that our internal APIs don't allow to check for status of a single character in isolation: we have to stick it in a String! See http://api.libreoffice.org/common/ref/com/sun/star/i18n/XCharacterClassification.html That's inconvenient with the current implementation of StringContains through StringPtrContains. However, StringPtrContains has only one direct caller, namely skipthousands. If this one (and thus all its callers) can be converted to using String-and-offset instead of pointer-to-buffer, things become sane again. Or maybe really we should have http://api.libreoffice.org/common/ref/com/sun/star/i18n/XCharacterClassification2.html to fix the "flaw" in XCharacterClassification of insisting on a string ;-) As a consequence of this messy situation, this goes above the effort / decision power I want to exert outside of my area. Another "proper" (but maybe less so in some ways, and more so in other ways) fix would be to make that parser backtracking instead of eager. That is, if an option fails, it still tries to go along the others. Also a lot of work :)
Created attachment 57408 [details] calc document to reproduce
Created attachment 57410 [details] in-progress patch
(In reply to comment #5) > Another "proper" fix would be to make that parser backtracking instead of > eager. That is, if an option fails, it still tries to go along the others. > Also a lot of work :) Actually, not as much as I thought yesterday, by far. I started dreaming that if only we were using a higher level programming language, we could just use a dynamic (at-runtime) parser generator for this parsing job, and then we just "plug in" the internationalised strings into the grammar definition, generate it, and use that parser. Some googling later, not only do dynamic parser generators exist for C++, but Boost (which we already use/bundle) has one, namely Boost::Spirit. From a cursory glance, it looks quite decent. So the idea of replacing that *whole* parsing code by a Boost::Spirit grammar is growing on me. Comments on that?
(In reply to comment #8) > So the idea of replacing that *whole* parsing code by a Boost::Spirit grammar > is growing on me. Comments on that? Yeah, don't ;-) Honestly, there are too many side conditions to consider, and with a Spirit parser we'd also loose the coupling with i18n I guess. Btw, your addition of isAlpha( sal_Unicode c ) et al to CharClass in in-progress.patch wouldn't work as the underlying CharacterClassification doesn't have a corresponding method on purpose, it only works on OUString and position. Actually using sal_Unicode for characters limits them to UCS2 and does not take UTF-16 e.g. surrogates into account, which the i18n methods handle using OUString::iterateCodePoints() Current code (not only in the number formatter) doesn't account for full UTF-16 in many places where it should iterate over code points instead of sal_Unicode, but that's a different story..
(In reply to comment #9) > (In reply to comment #8) >> So the idea of replacing that *whole* parsing code by a Boost::Spirit grammar >> is growing on me. Comments on that? > Yeah, don't ;-) > Honestly, there are too many side conditions to consider, and with a Spirit > parser we'd also loose the coupling with i18n I guess. I understand "coupling with i18n" as "using the isAlphaNumeric, etc from pFormatter->GetCharClass()", right? Well, today I've been toying with doing just that coupling, actually. I haven't *quite* got it working, but maybe with some upstream help? What kind of "side conditions" do you have in mind? > Btw, your addition of isAlpha( sal_Unicode c ) et al to CharClass in > in-progress.patch wouldn't work as the underlying CharacterClassification > doesn't have a corresponding method on purpose, it only works on OUString and > position. Actually using sal_Unicode for characters limits them to UCS2 and > does not take UTF-16 e.g. surrogates into account, which the i18n methods > handle using OUString::iterateCodePoints() Ah yes, our punishment for not using 32 bit characters (UCS-4). I see.
Confirmed on LibreOffice downloaded from http://dev-builds.libreoffice.org/pre-releases/deb/x86_64/ LibreOffice version: 4.3.0.0.alpha1 Build ID: 46cfcd5a05aa1d13fecd73f5a25b64b8d8dd6781 OS: Ubuntu 13.04 x86_64 Steps to reproduce: 1) Start LibreOffice Calc 2) Open the attached file https://bugs.freedesktop.org/attachment.cgi?id=57408 "calc document to reproduce" 3) enter "lunedì 9 maggio 2014" at position B2: properly formatted as a Date, and column C shows the numer of days between that date and today. 4) enter "martedì 10 maggio 2014" at position B3: shown as String, not formatted as Date. Column C gives error.
Eike Rathke committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8e71f81f47c20320c4de7a7aadb7d524f0d8ea76 resolved fdo#41166 match month and day name word instead of substring 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=3885b5d4b00ebb31adabc36c507abd642c03d0d4 resolved fdo#41166 match month and day name word instead of substring 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.
Pending review for 4-2 at https://gerrit.libreoffice.org/9387
Eike Rathke committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=41b9ab0375f455f504c66b4870e817aba0f990d2&h=libreoffice-4-2 resolved fdo#41166 match month and day name word instead of substring It will be available in LibreOffice 4.2.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.
Verified as fixed for LibreOffice Version: 4.3.0.0.alpha1+ Build ID: b5f45a51638901ea679bf238ab460283e41bc622 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-05-19_06:16:16 Best, Marina