Created attachment 153408 [details] screenshots and test database
Have tested the attached Firebird-Database with LO 6.3.0.4. Date format, choosen in the properties of the date-field of the tablecontrol, should be DD/MM/JJJJ (15/08/2019). When changing from editmode to input data it changes to DD.MM.JJJJ (15.08.2019). This seems to be the same with all frontslashes. Instead of frontslashes you could see points. My system: OpenSUSE 15 64bit rpm Linux.
Dear Dmitry Mikhailov, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Bug is still the same under LO 7.2.0.3 on OpenSUSE 15.2 64bit rpm Linux.
Bug is still the same LO version: 6.4.7.2 Linux 5.11; Locale: ru-RU (ru_RU.UTF-8) I guess, that '/' symbol substituted with default i18N.ru delimeter - '.' Thats why on en-EN locale this bug is not met.
recognition of date format is global problem in LO In Preferences, Language preferences - Language section, option "Date recognition patterns" - the default is "D.M.Y;D.M.;D/M/" also can be added "D/M/Y". but it doesn't affected on recognition of date in Calc, for example. try to input in cell any of "31/12/2021" or "31/12/21" or "1/1/22" or "31/12"- cell data will be remain as text I guess, that this bug affected any system, where locale setting implies that date delimeter is not '/'.
Dear Dmitry Mikhailov, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
This bug is unclear. There is no way for the report to define the controls' or fields' locale; as far as I see, the locale used is always the one set in Options->Languages and Locales->General. The en-US standard formats are suggested in field's editor; and the chosen standard format is automatically converted to the program's locale upon display, using the program's locale date separators. If I understand correctly, this is completely unrelated to Firebird. Also, this is an enhancement request to support per-control / per-field locale in forms. If this is correct, then please remove the "Blocks" issue, and change the importance accordingly. And there is nothing about *recognition* of dates in this report. It is about the existing data display. If there is some recognition problem, as mentioned in comment 5, it needs a separate issue. Especially when talking about Calc.
Has nothing special to do with Firebird. So I removed the block for Firebird here. Open the form for editing, not for input data. Right mousclick on column header a_date → Column. You will get the properties of the field, which is a special field for dates. (Nice to have for getting a calendar for choosing dates.) You could choose the format. It is independent from local settings. It has been set to DD/MM/YYYY When opening the form for input data it will only be sown as DD.MM.YYYY. Right mouseclick on header of table control → Insert column → Formatted field. This field could also read dates. It could be formatted to local settings England (Australia). There you could choose DD/MM/YYYY. Formatted field will show the date in the choosen format. Date field won't show the choosen format. All tested with Version: 24.8.0.1 (X86_64) / LibreOffice Community Build ID: 6fd6cae02baed1e82d14ed2da1f2458092354dab CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded
little bit weird... i disagree, that it is nothing special to do with Firebird. I, as user, confused, when interface suggest as field format choice of: 1. standart (short) 2. standart (short YY) 3. standart (short YYYY) 4. standart (long) 5. YY/MM/DD 6. MM/DD/YY 7. YY/MM/DD 5. YYYY/MM/DD 6. MM/DD/YYYY 7. YYYY/MM/DD and standalone SQL format (!!!) 8. YY-MM-DD 9. YYYY-MM-DD point from 1 to 4 is format of local settings point from 5 to 7 is date format where YY is substituted by year, etc..., and "/" is substituted by date delimeter. point from 8 to 9 is date format where YY is substituted by year, etc..., and "-" is NOT substituted by anything. also: dropdown menu contains not "YY/MM/DD", but only if locale is en_en you can see "YY/MM/DD", but if ru_ru, then menu is changing to "ГГ/ММ/ДД", so year month day placeholder is substituted in dropdaown menu, and date placeholder is not. so: I suggest to change current bug this way: form dropdown menu substituting not only year month day placeholders, but date delimeters too.
thank you for hack with formatted field. It is completely suit my needs. :)
Created attachment 195416 [details] Same behavior with HSQLDB - nothing specific Firebird Have taken the Firebird database and copied all to HSQLDB. Will show the same buggy behavior for a date control inside a tablecontrol. Same buggy behavior also for a stand alone date control, so not specific to a tablecontrol.