Apache OpenOffice (AOO) Bugzilla – Issue 24082
Problem with date 25/4/3 (where?) 2004-03-28 (EU) and probably soon (2004-04-03) with 2004-04-04 (US)
Last modified: 2013-08-07 15:00:27 UTC
Date 25.04.03 acts differently than others in spreadsheet: it doesn't follow formatting rules and it is generated wrong when populating dates by dragging cell's corner. How to produce: First problem: a) Open new spreadsheet and format a cell to have format DD.MM.YY b) Enter 23/4/3, 24/4/3 and 25/4/3 into the cell. You can also enter 23.4.3, format doesn't matter. 23.04.03 and 24.04.03 are formatted correctly, but 25.04. 03 is not. Second problem a) Format a cell to have format DD.MM.YY and enter date 01.04.03 b) Drag cell's bottom right corner down to populate dates increasingly into other cells of column. Dates are shown as 22.04.03, 23.04.03, 24.04.03, 24.04. 03, 26.04.03, 27.04.03. So 25.04.03 is also shown as 24.04.03. When you change cells format to number then all number are correct. Linux versions of 1.1.0 and 1.1.1a work correctly. Linux version of OOo acts correctly.
Hi, I'm sorry to tell you, but I can't reproduce the problem your facing. Neither with OOo 1.1 nor with 1.1.1a. As in the mean time noone else could reproduce your problem, I close it as worksforme. Please try it again and reopen this Issue if you get it reproducible even if you close the Office and reboot your machine. Thanks for your co-operation. Frank
closed wfm
Hi, I can still confirm that bug appears as reported. Installed 1.1.1a on new Windows 2000 and it's there. Also several users in our local list have confirmed it. I'll attach the screenshot.
Created attachment 12473 [details] screenshot that describes 25.04.03 appearance bug
Hi, a Screenshot will not help in this case. I believe that you're facing the problem, but it's not reproducible on other's systems. Do you have set a userdefined template as default template for Calc ? Have a look at File - Templates - Organize. Also what are the Locale settings for your w2k ? Is OOo1.1 an english version or has it a different language ? From there have you downloaded this version or have you build it by yourself ? Please also attach a document that shows your problem. Frank
I've played with it, but I've been unable NOT to produce this bug. It appears on Windows, it doesn't appear on Linux. I re-downloaded official OOo-1.1.0 for Windows, installed it on Windows Simpler steps to reproduce: * Open new spreadsheet * Enter date 22.04.03 (April 22 '03) into any cell so that it is correctly recognized as date, drag cell's lower right corner 10 cells down, so that dates are populated increasingly. Do you also see 23.04.03, 24.04.03, 24.04.03, 26.04.03? If I enter 25.04.03 into any cell, it is always treated as non-date, although any other dates 1-2 days smaller or bigger written in the same format are recognized correctly. I've changed OOo's locale and document language to different values, also Windows' locale, but no change. I've tried on English Win2000 and Win2003 Server.
so basically it looks to me like for some reason date-recognition ignores this particular date (25.04.03) and date formatting formats it wrong.
Hi, again, I can't reproduce your problem. Please attach a file that shows your problem. Frank
Hi, Could you please describe your environment too, on which problem doesn't appear? Gnumeric had similar problem and Jody Goldberg from Gnumericu team wrote about their bug: ....so it's compiler or compiler flag specific. The code for elapsed hours looks like its already doing epsilon rounding. ...Replication required an optimized build. We needed to add epsilon before scaling. Fixed. Could you check this please: http://bugzilla.gnome.org/show_bug.cgi?id=125230
Environment used: W2k English German locales WinXP Prof English German locales Solaris9 UltraSparc English English locales Turbo Linux 8 English English locales Suse Linux 8.1 English English locales Sun JDS English English locales On all machines the official build from OOo Versions 1.0.3.1, 1.1, 1.1.1a So you can see, this seems to be a problem with your Environment or build. Compilerflags maybe the problem, but only if you build the Inst. set by yourself. So please attach a document that shows the problem. Maybe we can find out whats going wrong if we analyze it. Frank
Hi Pezz, This seems to be a dupe of issue 17222, fixed on branch pp1numfor that was integrated on 2004-01-05, please verify in the next release of OOo1.1.1 In the meantime you might test if the behavior changes if you select another timezone / regional settings or so under Windows. Eike
OOo-1.1.1b really fixed the problem, so I close this issue.
closed fixed on users request
I want to reopen this bug because it appears again in 1.1.1rc3, tested with original and localized builds on win2k and suse 9.0. Now it appears with date 28.03.2004. If i enter 03/28 calc displays this as 1. Mar 2028, if i enter 03/28/2004 calc doesn't recognize this as a date. With 03/27 and 03/29 its all okay. I have tested it with us-english and estonian locale and using different basis dates as spreadsheet options, nothing. Bug is still here.
reopened
Hi Eike, could you have a look at this please? Frank
I made a screenshot with explanations and attached here, I think this is better than attaching the calc file, because in different systems this file may behave differently.
oops, forgot the file http://www.avkb.ee/dates.png
This wasn't broken with 1.1.1rc3, it started happening *today* (the day after the daylight saving switchover), with the changes for issue 17222.
Accepted issue, investigating.
*** Issue 27210 has been marked as a duplicate of this issue. ***
Identified the cause, happens when daylight saving time (DST) (with onsetRule time 02:00+1h for example) is in effect and the very onsetRule date 00:00-00:59 is entered via i18npool->ICU without resubmitting the time value after DST glitch correction. Should occur independent of locale as long as the DST condition is met. Adjusting summary accordingly. I regard this important enough to raise the release target to OOo1.1.2, fix is prepared. @Pezz: I still wonder how you encountered the problem with 2003-04-25 in January of 2004, which locale or timezone settings did your machine use? If the behavior of that date and the ones from issue 17222 was related (it seems so as you reported it to be fixed) it would had been something that resulted in switching DST on or off on that date, strangely enough a Friday, and your DST in January being the opposite. Eike
Fixed on branch cws_srx645_dr16: i18npool/source/calendar/calendar_gregorian.cxx -r1.21.26.1.10.1
Created attachment 14337 [details] StarBASIC script to verify behavior
Reassign to QA. Peter, you may also use the BASIC script attached to this issue to verify the behavior, just be sure to start the application in an environment where a de_DE locale and DST is effective. A complete test would also involve DST _not_ being effective (setting the machine's date to January or the like) and in the script use values that do similar transition from non-DST to DST.
This issues was also reported by Czech users.
*** Issue 27512 has been marked as a duplicate of this issue. ***
OK in CWS dr16. Script shows expected results. The cross-check on a locale not supporting DST fails. ->fixed/verified
.
*** Issue 27572 has been marked as a duplicate of this issue. ***
*** Issue 27717 has been marked as a duplicate of this issue. ***
*** Issue 27475 has been marked as a duplicate of this issue. ***
*** Issue 28033 has been marked as a duplicate of this issue. ***
*** Issue 28204 has been marked as a duplicate of this issue. ***
*** Issue 28199 has been marked as a duplicate of this issue. ***
*** Issue 28344 has been marked as a duplicate of this issue. ***
Fixed in master srx645m40
*** Issue 28451 has been marked as a duplicate of this issue. ***
*** Issue 28075 has been marked as a duplicate of this issue. ***
*** Issue 28598 has been marked as a duplicate of this issue. ***
*** Issue 28655 has been marked as a duplicate of this issue. ***
You seem to be confident that issue 28655 is a duplicate of this one, but I'm not so sure, as it has nothing to do with daylight saving. Issue 28655 was generated in a time zone where daylight saving is not active. I trust you're going to load the attachment from issue 28655 into your 1.1.2 fix and confirm that it provides the fix (?).
@geofffarell: Yes, I can confrim the duplicate. It's no problem of the timezone but of the locales selected. You can cross check it by running the macro Eike attached to this issue. Peter
*** Issue 29374 has been marked as a duplicate of this issue. ***
*** Issue 29861 has been marked as a duplicate of this issue. ***
*** Issue 29962 has been marked as a duplicate of this issue. ***
*** Issue 30060 has been marked as a duplicate of this issue. ***
*** Issue 30387 has been marked as a duplicate of this issue. ***
*** Issue 30803 has been marked as a duplicate of this issue. ***