Problem description: The date is not displayed correctly. Step which reproduces the following: The following dates are inputted into Cell of Calc. 1904-12-01 1932-01-01 1961-08-10 1968-10-01 The present behavior: 1904-11-30 1931-12-31 1961-08-09 1968-09-30 It was expected and acts: 1904-12-01 1932-01-01 1961-08-10 1968-10-01 Operating System: Windows 7 Version: 3.6.2.2 release
I confirmed this issue with Windows XP,8 and LibreOffice 3.6.4.3. Hi, Kohei. Please look at this issue.
I can't reproduce this using the latest build from the libreoffice-3-6 branch. 4.0 also behaves correctly as well. Tested on Linux.
Perhaps this ... 1) has been fixed since 3.6.4, or 2) is Windows specific?
Dear Mr.Kohei Yoshida I think that it is peculiar to a Windows version. Please correct immediately. I have spread using Libre in an office. It becomes difficult.
(In reply to comment #4) > Dear Mr.Kohei Yoshida > > I think that it is peculiar to a Windows version. Have you verified this by testing the Linux version?
This phenomenon was not set with the Linux version. However, since all the personal computers used in an office are Windows, please correct the Windows version.
We already had such problems that automatically a single day became added or subtracted after a Manual date input (I don't remember, have to check). As far as I remember those were related to time zone, OS UI language and/or LibO Locale @LibreFun, M.Kamataki: I understand that correctly, you manually type into the cell "1904-12-01" and then the date changes after TAB or Enter to 1904-11-30? Please - Attach your sample document you used to reproduce the bug - add information -- concerning your OS (Version, Distribution, Language) -- concerning your LibO version (with Build ID if it's not a public release) and localization (UI language, Locale setting in menu 'Tools -> Options -> Language Settings') -- Date recognition Pattern in menu 'Tools -> Options -> Language Settings' –- Libo settings that might be related to your problems
I remembered "Bug 44286 - [EDITING] Calc decreases one day of a date typed (Brazilian-portuguese locale and timezone)" for a similar effect (If I understood reporter correctly)
I cannot reproduce this issue using LibO 3.6.3.2 (UI English, Locale German) on Win7 Enterprise (en). This is irrespective of "YYYY-MM-DD" being included in the date recognition pattern or not. Reference date (Tools->Options->Calc->Calculate) is set to default (1899-12-30).
Cannot reproduce on my Linux distro. I followed the steps as posted by LibreFun and the dates worked as expected. Mageia Linux, LibreOffice 3.6.2.2 (Build ID: da8cle6). Marc
Can't reproduce using Windows 7 Ultimate SP1 x64 running on a MacBook Pro 13" mid 2010. Tested with LibreOffice 3.6.4.3 release and LibreOffice 4.0.0.2 rc2. Both tested with US-English UI and language settings as well as Dutch UI and language settings. I entered the dates in fields A1 to A4, saved it as ods and xlsx and reopened it. Kind regards, Joren
I recall this is a very old bug and I discussed with Eike in Budapest (2010). In my locale (pt_BR, DD/MM/YYYY), if I type 12/01/1904 <Enter> I get 11/01/1904. This is in LO 4.0 RC2 under Windows XP. If you type 12/01/1913, you also get 11/01/1913. But if you type 12/01/1914 you get the correct result. 1914 is the year when something shifted.
It may also be related to the fact that oy are on the right or left of the Greenwich meridian.
This is most certainly related to ICU historical timezone data and the shift of timezone offset at some point of date/time for the timezone in effect, similar to bug 44286. For comment #12 in Brazil that can be reproduced on Linux by setting the corresponding timezone before starting the program, so in bash TZ=America/Sao_Paulo libreoffice @LibreFun original submitter: What is your timezone?
(In reply to comment #14) @LibreFun original submitter: > What is your timezone? I am using LibreOffice in Japan. I think that a time zone is Tokyo. With the Linux version (ZorinOS6.1 Libre 3.5.4.2), it is reproduced normally. However, in combination with the following Windows, it is not reproduced correctly. WindowsXP Pro SP3 Libre 3.5.5.3Windows7 Libre 3.6.2.2 LibreFun
(In reply to comment #15) > With the Linux version (ZorinOS6.1 Libre 3.5.4.2), it is reproduced > normally. > However, in combination with the following Windows, it is not reproduced > correctly. Just to make sure that I understand correctly, "reproduced normally" means that the bug does occur, and "not reproduced correctly" means that the bug does not occur?
(In reply to comment #16) > (In reply to comment #15) > > With the Linux version (ZorinOS6.1 Libre 3.5.4.2), it is reproduced > > normally. > > However, in combination with the following Windows, it is not reproduced > > correctly. > > Just to make sure that I understand correctly, "reproduced normally" means > that the bug does occur, and "not reproduced correctly" means that the bug > does not occur? I'm not the reporter, but I'm pretty sure his "reproduces" actually means "works (no bug happens)". The meaning got reversed in the translation. ;-)
(In reply to comment #16) Hello Mr. Eike Rathke. My name is LibreFun. I discovered the Libre bug of the Windows version. I have not discovered the bug of Libre of the Linux version. Mr.Kohei Yoshida Thank you for helping me.
Having fixed this for bug 44286 and related I can not reproduce this specific case with TZ=Japan/Tokyo on Linux and would need to do a Windows build, but I strongly believe it has the same cause and should be fixed with that fix as well. If someone could verify with a Windows build, once available, of one of the versions mentioned in bug 44286 for which the fix has been committed?
Hi Eike, I've asked someone in the Japanese community, and he says this bug still persists, using the daily build that contains the mentioned fix.
This is caused by ICU's timezone detection bug (http://www.icu-project.org/trac/ticket/10129). In Japan, We should get JST(Japan Standard Time). But on Windows, ICU returns KST(Korea Standard Time). Currently JST and KST have same offset (UTC+9). But KST was changed several times in the past and maybe it causes this behavier. See also: http://translate.google.co.jp/translate?sl=ko&tl=en&js=n&prev=_t&ie=UTF-8&eotf=1&u=http%3A%2F%2Fko.wikipedia.org%2Fwiki%2F%ED%95%9C%EA%B5%AD_%ED%91%9C%EC%A4%80%EC%8B%9C&act=url&act=url
Patch added: https://gerrit.libreoffice.org/3636 Applying that fixes this bug. I confirmed this fix with Windows 8 Pro 64bit Japanese.
Sorry, I made a mistake writing commit comment and re-submit fixed patch. Please review fixed one: https://gerrit.libreoffice.org/3637
Isamu Mogi committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=263ab3f14bbb8cea9f5a1b8ea7496f6a23e6c547 fdo#59850: Resolves invalid date changing by ICU's timezone detection bug. 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.
I'll mark this fixed for 4.1. Backporting this to 4.0.x is a bit tricky since 4.0 uses a different icu version (?) and still uses dmake to build it.
Tor, Kohei, Eike Sorry for my badly slow work, the patch merged without an explanation. For that reason I write that here: u_strFromWCS() returns a wrong destination length for u_austrncpy() if apiTZI.StandardName is multibyte string. Therefore apiStdName will be incomplete string, and timezone detection (using apiStdName) returns invalid result. This will fix destination length for u_austrncpy() enough to write multibyte string.
Pending review for 4-0 as https://gerrit.libreoffice.org/3798 for 3-6 as https://gerrit.libreoffice.org/3800
Isamu Mogi committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f2cc7e08263a0fcca8b6dfe95ea74f4e7938103b&h=libreoffice-3-6 fdo#59850: Resolves invalid date changing by ICU's timezone detection bug. It will be available in LibreOffice 3.6.7. 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.
Isamu Mogi committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=2acdef7ee40179c7bc5e9510ad1ddc1266d053ab&h=libreoffice-4-0 fdo#59850: Resolves invalid date changing by ICU's timezone detection bug. It will be available in LibreOffice 4.0.4. 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.
The bug has revived by LibreOffice4.3.
The ICU bug referenced in the previous patch (https://ssl.icu-project.org/trac/ticket/10129) was fixed in ICU 52.1, which LibreOffice upgraded to in 4.2. The location of the patch in ICU (in icu/source/common/wintz.c) was then changed again in a different way in ICU 53.1, which LibreOffice upgraded to as of 4.3. If this later change in ICU has reintroduced the bug then it needs reopening upstream, and LO may need to carry another local patch until it gets re-fixed.
@LibreFun: Instead of reopening this, you probably are hit by bug 63230 instead? @Isamu: Resetting all field values was a bad idea. Also note that the Version field indicates the earliest version the bug was observed. Setting back to previous state unless someone can identify the problem really being the specific Windows timezone problem described and patched here.
Hi Eike. It understood. I watch transition of the argument on bug 63230.