Could confirm this bug special for the date 1893/04/01. If I write a date 1893/04/01 it is shown as 1893/03/31. If I open the same table in LO 3.3.4 it shows 1893/04/01.
This regression first appears in LO 3.4.0beta1. The last working version was 3.3.4
My System: OpenSUSE 12.3 64bit rpm Linux.
I set the version to the first the bug appeared.

Created attachment 95238 [details]
Query shows: The date is saved right, it is shown wrong in the GUI

A database with one table. A datefield and a timestamp-field, also two varchar-fields for showing the expected values. Open the query. It shows (for this bug) the input into the datefield as date and as varcharfield. Also shows, which Day and which Month is saved in the internal HSQLDB database.
The date seems to be saved right, but is shown wrong in the GUI.

I think it can be the same issue, or at least the same root as in https://bugs.freedesktop.org/show_bug.cgi?id=74869, OS time zone affects some dates.

Adding self to CC if not already on

The bug seems to have been fixed in the meanwhile.

I just tried this again with different LibreOffice versions (provided at the following URL: https://downloadarchive.documentfoundation.org/libreoffice/old/).

I can reproduce the issue with "4.3.3.2_Linux_x86-64_deb" and "LibreOffice_4.4.5.2_Linux_x86-64", but no longer with "LibreOffice_5.0.1.1_Linux_x86-64".

I also cannot reproduce the issue with a recent master build from the lo-linux-dbgutil bibisect repository. I tried commit fde19a183e7f8b1623c4db5071ad7f66b1b7e1c9 (source-hash-e0b0501452e6a72ba800ae9f536d766f8111ed78) of 2015-08-19.

Please provide feedback if you should still observe this behaviour with the most recent LibreOffice version; otherwise it will be considered fixed.

Right, works with LO 5.0.1.1, doesn't work with LO 4.4.5.2 on OpenSUSE 13.2 64bit rpm Linux.

I (bi)bisected (using the bibisect-50max repo) to find out where this bug was fixed.
Notice, that "good" and "bad" were therefore used in the opposite way as for normal bisecting, i.e. commits marked as "bad" do not contain the bug.

In order to also fix this in LibreOffice 4.4, the following commit would have to be cherry-picked.

 7b1e8c3d767d79daf0019f7a30d1016fff233514 is the first bad commit
commit 7b1e8c3d767d79daf0019f7a30d1016fff233514
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Wed May 27 18:26:21 2015 +0800

    source-hash-c72cd80f4503f54f6c79cdc1ab03b0654663f488
    
    commit c72cd80f4503f54f6c79cdc1ab03b0654663f488
    Author:     Eike Rathke <erack@redhat.com>
    AuthorDate: Sat Jan 24 02:15:44 2015 +0100
    Commit:     Eike Rathke <erack@redhat.com>
    CommitDate: Mon Jan 26 18:12:17 2015 +0100
    
        use XCalendar4 local date/time in CalendarWrapper, tdf#63230
    
        Replaces the three-step timezone+DST correction. Hopefully ICU does take these
        into account, but this needs to be double-rechecked and if necessary
        correction be implemented at XCalendar4::setLocalDateTime()
    
        See also
        http://userguide.icu-project.org/datetime/calendar#TOC-Ambiguous-Wall-Clock-Time-Resolution
        Interpreting as standard time for non-existing times sounds like what we need
        and covers the dreaded "00:00-01:00 doesn't exist" case that decremented the
        day and was fixed here with the now removed workaround.

:040000 040000 da30e9ca8c6735014ebbeef166cc0a12cd4eeac9 910edab0b72a0e2d35518c5d45620ae40a3f245d M	opt

---

$ git bisect log
# bad: [dda106fd616b7c0b8dc2370f6f1184501b01a49e] source-hash-0db96caf0fcce09b87621c11b584a6d81cc7df86
# good: [5b9dd620df316345477f0b6e6c9ed8ada7b6c091] source-hash-2851ce5afd0f37764cbbc2c2a9a63c7adc844311
git bisect start 'latest' 'oldest'
# bad: [0c30a2c797b249d0cd804cb71554946e2276b557] source-hash-45aaec8206182c16025cbcb20651ddbdf558b95d
git bisect bad 0c30a2c797b249d0cd804cb71554946e2276b557
# skip: [770ff0d1a74d2450c2decb349b62c5087e12c46b] source-hash-549b7fad48bb9ddcba7dfa92daea6ce917853a03
git bisect skip 770ff0d1a74d2450c2decb349b62c5087e12c46b
# good: [d79a82cf8709fb0e5e97e774ea41bcc5f00ba764] source-hash-27a166bcb8bdf56efff987b08895d2c676125426
git bisect good d79a82cf8709fb0e5e97e774ea41bcc5f00ba764
# bad: [4df59096bdd4164bf22f38ba321e5f65ce22b3a9] source-hash-c97dbb56596eecd19d73a0adb49f9de1ee279e14
git bisect bad 4df59096bdd4164bf22f38ba321e5f65ce22b3a9
# good: [cad6db30fb53cde7f1c00eed410e16d25fae0c60] source-hash-3dade5461b1644899dac694bb348d1bd5b4bea5c
git bisect good cad6db30fb53cde7f1c00eed410e16d25fae0c60
# good: [3364a85463fad5fb80b5f7faa57fbaacd35a7fb0] source-hash-2987f8d8d6bb005814660a1a10a5eebb74aef312
git bisect good 3364a85463fad5fb80b5f7faa57fbaacd35a7fb0
# bad: [77020e093586ba51a8752bea2b7638024ab2fb69] source-hash-7daf15884d980a8b848f3bdf9bdaed498dcb7b55
git bisect bad 77020e093586ba51a8752bea2b7638024ab2fb69
# good: [20c2c8c386efb718801ed770c873dab67e691bef] source-hash-dada981a72e47b03d77e8643a8cbeb6b219ecfac
git bisect good 20c2c8c386efb718801ed770c873dab67e691bef
# bad: [8e7c3329d9c245bbce53105cc67e090fb7eafe2d] source-hash-779581feed4886313746a71e9e738d736977be1b
git bisect bad 8e7c3329d9c245bbce53105cc67e090fb7eafe2d
# good: [c210e34403f54c02f24671cad5d7bd5bacff517c] source-hash-3f5ccf572a12d1ac54d47ab7fcdc23f7bb8f132b
git bisect good c210e34403f54c02f24671cad5d7bd5bacff517c
# bad: [7c5c82b0d8d31255f4b89ca19d98deaf0edd6446] source-hash-92fd7a6b029e6ebad651a0e4636fa9c9229c931c
git bisect bad 7c5c82b0d8d31255f4b89ca19d98deaf0edd6446
# good: [c88a5e6e93ce8c7cc45901b7f90d961d1bf82dd7] source-hash-15e1c881684c0127c0ca989924bbf2508b4fd780
git bisect good c88a5e6e93ce8c7cc45901b7f90d961d1bf82dd7
# bad: [7b1e8c3d767d79daf0019f7a30d1016fff233514] source-hash-c72cd80f4503f54f6c79cdc1ab03b0654663f488
git bisect bad 7b1e8c3d767d79daf0019f7a30d1016fff233514
# good: [ef1a7e8b5cd5739138fa4330f228bd1ff380315b] source-hash-cd528c3099ffec4f34565820b923d6385478e44b
git bisect good ef1a7e8b5cd5739138fa4330f228bd1ff380315b
# first bad commit: [7b1e8c3d767d79daf0019f7a30d1016fff233514] source-hash-c72cd80f4503f54f6c79cdc1ab03b0654663f488

According to comments 22 and 23 in bug 63230 (which is addressed by the above mentioned commit), some more patches might be involved and - as far as I understand it - Eike mentioned there that backporting those to LibreOffice 4.4 might only be done with a certain amount of caution...

Migrating Whiteboard tags to Keywords: (bibisectRequest)
[NinjaEdit]