Problem description: Steps to reproduce: 1. Right click on a cell, select "format cells" 2. For "Category" select "Date", and for "format" select "31/12/99" 3. Type into the cell: 02/01/12 Current behavior: The date is interpreted according to the current locale. If the current locale is USA, it is interpreted as February 1 and it comes out displayed as "01/02/12" Expected behavior: The date should be interpreted according to the format that has been assigned to the cell. So since the cell is formatted as "31/12/99", it should be interpreted as January 2 and it would show up as you typed it. Platform (if different from the browser): Browser: Mozilla/5.0 (X11; Linux i686) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11
Hi. There is also a major problem with date formatting in "Version 3.6.1.2 (Build ID: e29a214)". OS = XP sp3, norwegian. Whenever a cell is formatted as date (or not), Calc should threat the input as date. If I write "21.8" (without hyphens) the expected behaviour is that Calc should threat it as august 21 2012 - or whatever year it is. Instead, Calc just treat the input as string equal to "21.8". However if I write "21.8.12" then Calc threat the input as date as expected.
Cannot reproduce with LibO 3.6.3.2 Marking as WORKSFORME. Please try on latest stable release, if it's still a problem reopen as UNCONFIRMED. Thanks for your patience and for helping us make LibO better for everyone :)
Oh my god this god closed!!! The issue is still present in 4.0.2.2
Please don't play around with the severity/importance to try to raise awareness for your pet bug. Reverting change. Also this bug was never confirmed by our QA team, moving to UNCONFIRMED.
Did I change the importance/priority? I don't remember and I don't see a history of that, but if I did, I wasn't "playing around", I was just changing the value to what I deemed correct. If you think users or bug reporters should not edit priority/importance settings, then you should restrict them to project maintainers or whomever you consider should be solely responsible of deciding that. This is not my "pet bug", this is just an annoying bug as any other. Regarding this: > Also this bug was never confirmed by our QA team, moving to UNCONFIRMED. Well, then why don't you TRY IT, so that you can either confirm or invalidate it? Frankly, I think the person who marked this as "worksforme" simply didn't read my description carefully enough and did not follow the steps I provided to reproduce. I may be wrong about that, but please try again. I'm under the impression that it got dismissed not because it couldn't be reproduced, but because the behavior is perhaps "as intended", in which case you need to realize that it is the wrong behavior. Please follow the steps I provided to reproduce. If they don't reproduce the issue for you, please describe the outcome, and if it really is different from what I described, then let me know what additional information I need to provide about my setup that may be different from yours.
On Ubuntu with English locale, if I format a cell with Italian style date and input 02/01/12, it stays as 02/01/12. Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+ Build ID: 5bff4b016c4b44f4123e0e6a4fd4c0c4dc0cfa2d TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-13_00:14:29 and Version: 4.3.3.2 Build ID: 430m0(Build:2)
Can reproduce the behaviour with master (4.5.0.0alpha0+): -locale is set to Ducht (nl-NL) -cell format is set to MM/DD/YY -when entering 1-2-12, 02/01/12 is displayed -when entering 1/2/12, 02/01/12 is displayed This behaviour is as I expected it to be. The locale dictates how entered dates are handled (in the case of nl-NL, that is dd-mm-yy) and the cell format dictates how a date value is displayed. IMHO this is not a bug. I leave it to Matteo or QA to decide if the status should be resolved/notabug.
> This behaviour is as I expected it to be. > The locale dictates how entered dates > are handled (in the case of nl-NL, that is dd-mm-yy) > and the cell format dictates how a date value is displayed. Exactly. I thought I had made that pretty clear in the original report two years and a half ago. To me it seem obvious that it is not the right behavior. It is counterintuitive that dates are not displayed the same way as they are entered. I open a spreadsheet, see some dates, and the most obvious thing I expect is to be able to type them in the same format they are displayed, regardless of the locale of the computer where I'm opening the file. I do understand that may be users who would prefer the current behavior. For example, if you happen to often enter data into spreadsheets that are not in your own language, and you want to enter the dates in the way you are accustomed to write them. So in my opinion the best option would be to have a setting to deternine whether input is parsed according to current locale or according to cell format. Until then, it should be done according to cell format.
> It is counterintuitive that dates are not displayed the same way > as they are entered. I rephrase: It is counterintuitive that dates are not parsed the same way as they are displayed.
(In reply to matteo sisti sette from comment #8) In comment #7 I gave two different entries for a date with a meaning. If the locale is DD-MM-YY and the cell display format is MM/DD/YY, how should 1-2-12 be interpreted? Following the display format if the entered data exactly adheres to the display format and following the locale if not, is counterintuitive as well. The present behaviour (use locale for input and display format for output) and is not the behaviour you want, but at least it's consistent. I'm a developer, not a user interface specifier, so my view is biased towards 'does it work as designed'. (And my aim is to fix bugs.) Quite possibly in your view the design should be changed. In that case you should set the bug importance not to normal, but to enhancement.
> In comment #7 I gave two different entries for a date with a meaning. If the locale is DD-MM-YY and the cell display format is MM/DD/YY, how should 1-2-12 be interpreted? Following the display format if the entered data exactly adheres to the display format and following the locale if not, is counterintuitive as well. I get your point but i think there is a simple, intuitive AND consistent answer: - use the ORDER of months, days, year, regardless of the separators and number of digits, of the display format (and of course, if the entered data only has a meaning if interpreted in a given way, use the one that has a meaning, but I think it already does that; except for a bug reported elsewhere where +1 is added to the year in some cases without a reason) > Quite possibly in your view the design should be changed. > In that case you should set the bug importance not to normal, but to enhancement. I don't agree with that. If what I'm proposing is an enhancement to a design that could arguably be improved for a better user experience, then it is an enhancement. But if the design is plain wrong, then it is as much of a bug as "not working as designed", only that the bug is in the design rather than in the code implementing it. Of course it may be questioned whether the design is actually wrong. I'm saying it it. I hope someone from the specs teams (if there is one) reviews it.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.6 or 5.2.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170103
The bug is still present. Version: 6.1.2.1 Build ID: 1:6.1.2-0ubuntu1 CPU threads: 4; OS: Linux 4.18; UI render: default; VCL: gtk3_kde5; Locale: en-US (en_US.UTF-8); Calc: group threaded
Dear matteo sisti sette, 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 http://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
> 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. This is a shitty way to handle bug reports. Ïf you haven't touched a bug for over a year and have a reason to think it might have fixed itself, then you go and retest. Otherwise you leave it open. Especially if it had already been confirmed, it should be considered to be still there until proven otherwise, not the other way around.
(In reply to phoebe from comment #16) > > 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. > > This is a shitty way to handle bug reports. > Ïf you haven't touched a bug for over a year and have a reason to think it > might have fixed itself, then you go and retest. > Otherwise you leave it open. Especially if it had already been confirmed, it > should be considered to be still there until proven otherwise, not the other > way around. Nah, not a shitty way by far. We have consistently gotten around 25% close rate for methodically retested reports in this way. This is mostly because many of the reports are duplicates. The reports are in no way in danger of closing.
Oh I see, my bad, I thought that was saying that the bug would be automatically closed after a given period of time if not retested and reconfirmed.
Dear matteo sisti sette, 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