Bug 91249 - dates are moved one day back when going from v4.3.3.2
Summary: dates are moved one day back when going from v4.3.3.2
Status: RESOLVED DUPLICATE of bug 63566
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected) release
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2015-05-13 03:06 UTC by Piotr Matuszewski
Modified: 2015-05-29 14:56 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:

one table with key and date column, should be last day of 2014 and first of 2015 (3.37 KB, application/vnd.oasis.opendocument.database)
2015-05-13 03:06 UTC, Piotr Matuszewski
file changed by loading into (3.37 KB, application/vnd.oasis.opendocument.database)
2015-05-13 03:09 UTC, Piotr Matuszewski
screenshot with /etc/timezone set to Europe/Warsaw (44.81 KB, image/png)
2015-05-13 04:25 UTC, Piotr Matuszewski
screenshot with /etc/timezone missing (44.91 KB, image/png)
2015-05-13 04:27 UTC, Piotr Matuszewski

Note You need to log in before you can comment on or make changes to this bug.
Description Piotr Matuszewski 2015-05-13 03:06:17 UTC
Created attachment 115533 [details]
one table with key and date column, should be last day of 2014 and first of 2015

all date fields are changed one day to the past
this is real change, as after reopening in it stays changed
I'm on debian testing/unstable
Comment 1 Piotr Matuszewski 2015-05-13 03:06:46 UTC
ups, when going from to
Comment 2 Piotr Matuszewski 2015-05-13 03:09:22 UTC
Created attachment 115534 [details]
file changed by loading into
Comment 3 Piotr Matuszewski 2015-05-13 04:14:23 UTC
bug traced down to missing /etc/timezone on the faulty machine
Comment 4 Joel Madero 2015-05-13 04:22:40 UTC
Just to clarify some steps here:

1. Open file changed by loading into on a system with
2. Open table (only table in the file)

Dates should show 12.31.2014 & 01.01.2015

3. Open same file in

Dates show 12.30.2014 & 12.31.2014

(off by one day)

I cannot confirm that the "right" date (12.31 & 01.01) ever appear. I tested with every possibly combination with fresh profile and what not and never saw 12.31 and 01.01
Comment 5 Piotr Matuszewski 2015-05-13 04:25:00 UTC
Created attachment 115535 [details]
screenshot with /etc/timezone set to Europe/Warsaw
Comment 6 Piotr Matuszewski 2015-05-13 04:27:43 UTC
Created attachment 115536 [details]
screenshot with /etc/timezone missing
Comment 7 Piotr Matuszewski 2015-05-13 04:32:33 UTC
the file stays modified after restoring /etc/timezone
Comment 8 Piotr Matuszewski 2015-05-13 04:45:07 UTC
new version of procedure:

I'm using /etc/timezone set to Europe/Warsaw
I open the file in lobase and it works OK
after removing /etc/timezone lobase shows dates one day older then they should be
restoring /etc/timezone allows me to work with uncorrupted files, but the corrupted stay that way
Comment 9 Piotr Matuszewski 2015-05-13 04:48:17 UTC
lobase asks before saving modified file
lobase quietly writes corrupted fils
Comment 10 Piotr Matuszewski 2015-05-13 05:18:42 UTC
Alternating between TZ Europe/Warsaw and Pacific/Midway causes consistent drift of one day per cycle (the lobase needs to be restarted after the change of /etc/timezone for the effect)
the interaction of data modification and quiet autosave on quit is particularly nasty
Comment 11 Piotr Matuszewski 2015-05-13 06:02:56 UTC
I'm using default db engine - hsql
Comment 12 Alex Thurgood 2015-05-14 10:53:32 UTC
Tested on OSX 10.10.3

Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72

Table shows

Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6
Locale : fr_

Same results

So a Linux/distrib specific problem ?
Comment 13 Robert Großkopf 2015-05-14 14:49:09 UTC
Couldn't it be a duplicate of https://bugs.documentfoundation.org/show_bug.cgi?id=63566?
The problem exists since the first version of LO ...
Comment 14 Alex Thurgood 2015-05-14 14:55:43 UTC
Could be Robert.

Well, *buntu derivatives had java-tz update pushed just the other day, so maybe linked.

@Piotr : which Linux OS are you using ?
Comment 15 Alex Thurgood 2015-05-14 15:00:31 UTC
If it is, then it seems from Lionel's comments in that bug report that it ia a hsqldb problem, not much we can do about that I suspect.

if this is a DUP of bug 63566, it potentially means that embedded hsqldb 1.8 can not be relied upon to handle timestamps accurately, if it is dependent on the distrib providing an uptodate java-tz package.
Comment 16 Alex Thurgood 2015-05-14 15:05:43 UTC
This might be relevant too :

Comment 17 Alex Thurgood 2015-05-14 15:20:40 UTC
Sems like one might be able to work around the problem :

Comment 18 Alex Thurgood 2015-05-29 14:56:17 UTC

*** This bug has been marked as a duplicate of bug 63566 ***