Download it now!
Bug 59850 - EDITING: typed date decreased one day
Summary: EDITING: typed date decreased one day
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.6.2.2 release
Hardware: Other Windows (All)
: medium normal
Assignee: Eike Rathke
URL:
Whiteboard: BSA target:4.1.0 target:3.6.7 target:...
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-25 13:16 UTC by LibreFun
Modified: 2014-08-28 06:59 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description LibreFun 2013-01-25 13:16:48 UTC
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
Comment 1 M.Kamataki 2013-01-27 08:58:01 UTC
I confirmed this issue with Windows XP,8 and LibreOffice 3.6.4.3.

Hi, Kohei. Please look at this issue.
Comment 2 Kohei Yoshida 2013-01-28 14:51:35 UTC
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.
Comment 3 Kohei Yoshida 2013-01-28 14:59:57 UTC
Perhaps this ...

1) has been fixed since 3.6.4, or

2) is Windows specific?
Comment 4 LibreFun 2013-01-28 15:15:53 UTC
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.
Comment 5 Kohei Yoshida 2013-01-28 15:29:48 UTC
(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?
Comment 6 LibreFun 2013-01-28 15:51:00 UTC
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.
Comment 7 Rainer Bielefeld Retired 2013-01-28 16:10:21 UTC
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
Comment 8 Rainer Bielefeld Retired 2013-01-28 16:16:25 UTC
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)
Comment 9 Patrick Oltmann 2013-01-28 16:28:09 UTC
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).
Comment 10 Marc Pare 2013-01-28 16:38:08 UTC
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
Comment 11 Jorendc 2013-01-28 17:18:29 UTC
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
Comment 12 Olivier Hallot 2013-01-28 19:41:40 UTC
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.
Comment 13 Olivier Hallot 2013-01-28 19:42:44 UTC
It may also be related to the fact that oy are on the right or left of the Greenwich meridian.
Comment 14 Eike Rathke 2013-01-28 21:28:25 UTC
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?
Comment 15 LibreFun 2013-01-29 01:03:47 UTC
(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
Comment 16 Eike Rathke 2013-02-06 17:50:22 UTC
(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?
Comment 17 Kohei Yoshida 2013-02-06 18:07:55 UTC
(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. ;-)
Comment 18 LibreFun 2013-02-07 12:37:59 UTC

(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.
Comment 19 Eike Rathke 2013-03-26 12:51:29 UTC
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?
Comment 20 Kohei Yoshida 2013-04-17 14:36:53 UTC
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.
Comment 21 Isamu Mogi 2013-04-27 16:26:39 UTC
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
Comment 22 Isamu Mogi 2013-04-27 16:34:20 UTC
Patch added: https://gerrit.libreoffice.org/3636
Applying that fixes this bug. I confirmed this fix with Windows 8 Pro 64bit Japanese.
Comment 23 Isamu Mogi 2013-04-27 16:42:48 UTC
Sorry, I made ​​a mistake writing commit comment and re-submit fixed patch.
Please review fixed one: https://gerrit.libreoffice.org/3637
Comment 24 Commit Notification 2013-05-02 15:14:51 UTC
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.
Comment 25 Kohei Yoshida 2013-05-03 11:55:15 UTC
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.
Comment 26 Isamu Mogi 2013-05-06 12:54:17 UTC
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.
Comment 27 Eike Rathke 2013-05-10 14:42:52 UTC
Pending review
for 4-0 as https://gerrit.libreoffice.org/3798
for 3-6 as https://gerrit.libreoffice.org/3800
Comment 28 Commit Notification 2013-05-13 10:34:52 UTC
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.
Comment 29 Commit Notification 2013-05-13 10:43:18 UTC
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.
Comment 30 LibreFun 2014-08-25 14:39:23 UTC
The bug has revived by LibreOffice4.3.
Comment 31 Matthew Francis 2014-08-26 05:29:13 UTC
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.
Comment 32 Eike Rathke 2014-08-26 08:55:52 UTC
@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.
Comment 33 LibreFun 2014-08-26 11:46:05 UTC
Hi Eike.
It understood. 
I watch transition of the argument on bug 63230.