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 4.3.3.2 it stays changed I'm on debian testing/unstable
ups, when going from 4.3.3.2 to 4.4.2.2
Created attachment 115534 [details] file changed by loading into 4.4.2.2
bug traced down to missing /etc/timezone on the faulty machine
Just to clarify some steps here: 1. Open file changed by loading into 4.4.2.2 on a system with 4.3.2.2 2. Open table (only table in the file) Observed: Dates should show 12.31.2014 & 01.01.2015 3. Open same file in 4.4.2.2 Observed: 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
Created attachment 115535 [details] screenshot with /etc/timezone set to Europe/Warsaw
Created attachment 115536 [details] screenshot with /etc/timezone missing
the file stays modified after restoring /etc/timezone
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
lobase 4.3.3.2 asks before saving modified file lobase 4.4.3.2 quietly writes corrupted fils
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
I'm using default db engine - hsql
Tested on OSX 10.10.3 Version: 4.1.4.2 Build ID: 0a0440ccc0227ad9829de5f46be37cfb6edcf72 Table shows 01/01/2015 31/12/2014 Version: 4.4.2.2 Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6 Locale : fr_ Same results So a Linux/distrib specific problem ?
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 ...
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 ?
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.
This might be relevant too : http://www.jvmhost.com/articles/java-and-timezones
Sems like one might be able to work around the problem : http://jgrasstechtips.blogspot.fr/2007/12/hsqldb-and-timezones-no-gap-filled-yet.html
*** This bug has been marked as a duplicate of bug 63566 ***