Bug 91022 - Incorrect Dates in Report created with legacy report wizard
Summary: Incorrect Dates in Report created with legacy report wizard
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
4.4.0.0.beta1
Hardware: All Linux (All)
: medium major
Assignee: Julien Nabet
URL:
Whiteboard: target:5.1.0 target:5.0.2
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2015-05-02 14:08 UTC by Joe
Modified: 2016-10-25 19:20 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
Example LO Database File showing incorrect Dates in Report (12.81 KB, application/vnd.oasis.opendocument.database)
2015-05-02 17:16 UTC, Joe
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joe 2015-05-02 14:08:59 UTC
Apologies if this is in the wrong place (my first bug report)

The dates in Report Builder are incorrect by 2 days (behind).
(I'm running on Ubuntu 14.04 (Using PPA http://ppa.launchpad.net/libreoffice/libreoffice-4-4/ubuntu), however, same issue occurs on Windows version.

This may be a recurring bug (i.e it was first detected Bug 67186 - though this appears to have been resolved and fixed)
Comment 1 Julien Nabet 2015-05-02 16:36:35 UTC
Could you attach an example by using this link: https://bugs.documentfoundation.org/attachment.cgi?bugid=91022&action=enter ?
Comment 2 Joe 2015-05-02 17:16:24 UTC
Created attachment 115273 [details]
Example LO Database File showing incorrect Dates in Report

The TimeStamps in the Database table are 1/5/2015 14:00 (1 May 2015) but in the Reports they are displayed as 29/4/2015.
Comment 3 Robert Großkopf 2015-05-02 20:16:26 UTC
I could reproduce the bug for all LO-versions since LO 4.4.0.0 beta1. All versions before (except all 4.0-versions) give the correct date in the report, created by the legacy report-wizard.

Remember: Standard of LO is the Report-Builder, not the old legacy wizard.

My system: OpenSUSE 13.2 64bit rpm Linux.
Comment 4 Ravi 2015-07-14 22:09:49 UTC
Could reproduce this in latest version 4.4.4.3, Windows 64 bit.
Comment 5 Matthew Francis 2015-08-16 10:01:25 UTC
This seems to have begun at the below commit.
(Can't immediately see a BZ account for the author to Cc:)

commit 5d8ecad569fd7a254902da154ed8057ec61f3a83
Author: Robert Antoni Buj i Gelonch <robert.buj@gmail.com>
Date:   Wed Oct 29 17:34:18 2014 +0100

    java: Method uses the same code for two switch clauses
    
    Change-Id: Ied82b0a39ff9dc9c7cc9539dec2b963059f3d4a5
    Reviewed-on: https://gerrit.libreoffice.org/12139
    Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
    Tested-by: Noel Grandin <noelgrandin@gmail.com>


Specifically this hunk looks pretty suspicious to me

             case DataType.TIME: // ==  92;
+            case DataType.TIMESTAMP: // ==  93;
                 oAny = getColumnDoubleValue(ColIndex, false);
                 break;
 
-            case DataType.TIMESTAMP: // ==  93;
-                oAny = getColumnDoubleValue(ColIndex, true);
Comment 6 Alex Thurgood 2015-08-29 05:58:10 UTC
Adding committer Robert to CC
@Robert : any idea here why this might have happened ?
Comment 7 Julien Nabet 2015-08-31 21:00:11 UTC
On pc Debian x86-64 with master sources updated today, I could reproduce this.

Matthew: you were right! I tried this:
diff --git a/wizards/com/sun/star/wizards/db/RecordParser.java b/wizards/com/sun/star/wizards/db/RecordParser.java
index b71ae99..21be84a 100644
--- a/wizards/com/sun/star/wizards/db/RecordParser.java
+++ b/wizards/com/sun/star/wizards/db/RecordParser.java
@@ -131,12 +131,14 @@ public class RecordParser extends QueryMetaData
             case DataType.FLOAT: // ==   6;
             case DataType.REAL: // ==   7;
             case DataType.DOUBLE: // ==   8;
-            case DataType.DATE: // ==  91;
             case DataType.TIME: // ==  92;
-            case DataType.TIMESTAMP: // ==  93;
                 oAny = getColumnDoubleValue(ColIndex, false);
                 break;
 
+            case DataType.DATE: // ==  91;
+            case DataType.TIMESTAMP: // ==  93;
+                oAny = getColumnDoubleValue(ColIndex, true);
+                break;
             case DataType.CHAR: // ==   1;
             case DataType.VARCHAR: // ==  12;
             case DataType.LONGVARCHAR: // ==  -1;

and this worked!

Would you mind preparing a patch for gerrit or would you prefer I do it? (it's equal for me since the patch is already there on my laptop! :))
Comment 8 Matthew Francis 2015-09-01 01:04:50 UTC
(In reply to Julien Nabet from comment #7)
> Would you mind preparing a patch for gerrit or would you prefer I do it?
> (it's equal for me since the patch is already there on my laptop! :))

Please feel free, I have lots of other things going on right now :) Thanks
Comment 9 Julien Nabet 2015-09-01 05:30:03 UTC
(In reply to Matthew Francis from comment #8)
> Please feel free, I have lots of other things going on right now :) Thanks
Done! https://gerrit.libreoffice.org/#/c/18210/
Comment 10 Commit Notification 2015-09-01 07:56:57 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ed33646cdecac866ab480bf5770726b4a5bfa6c9

tdf#91022: Incorrect Dates in Report created with legacy report wizard

It will be available in 5.1.0.

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 11 Ravi 2015-09-01 08:08:27 UTC
I believe this may need another look. Although I came across this bug in LO Base Report Builder, just yesterday I found a similar bug in LO Calc (5.0.0.5) too. The date gets advanced by 2 days when it is imported as part of unformatted text with delimiters into Calc. The given patch seems to address report builder. Would it work for Calc text import too? If not, the actual root bug may possibly be elsewhere and causing the issue common to both Base and Calc.
Comment 12 Commit Notification 2015-09-01 08:32:46 UTC
Julien Nabet committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=f46d8fd4862bd1a2872f02f132c2267d08a1526c&h=libreoffice-5-0

tdf#91022: Incorrect Dates in Report created with legacy report wizard

It will be available in 5.0.2.

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 13 Julien Nabet 2015-09-01 08:45:19 UTC
(In reply to Ravi from comment #11)
> I believe this may need another look. Although I came across this bug in LO
> Base Report Builder, just yesterday I found a similar bug in LO Calc
> (5.0.0.5) too. The date gets advanced by 2 days when it is imported as part
> of unformatted text with delimiters into Calc. The given patch seems to
> address report builder. Would it work for Calc text import too? If not, the
> actual root bug may possibly be elsewhere and causing the issue common to
> both Base and Calc.

There was indeed a regression here.
Indeed, the given patch addresses only legacy report builder so it won't work for Calc.
Could you please open a new bugtracker?
Comment 14 Robinson Tryon (qubit) 2015-12-17 09:03:03 UTC Comment hidden (obsolete)