Red Hat Bugzilla – Bug 172305
Dates become 1/1/70 using OpenOffice Base files with gcj
Last modified: 2007-11-30 17:11:16 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050922 Fedora/1.0.7-1.1.fc4 Firefox/1.0.7
Description of problem:
When I create a database in a file with a date field in ooo base, the date turns into 1/1/70 as soon as the record is stored. This happens whether I enter the date in a form or in a table. The problem seems to be related to gcj, because I switched to Sun's java and restarted ooo base, and then the dates work fine. If I switch back to gcj, the dates all display as 1/1/70 again.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Start open office.
Go to Tools, Options, Java, and set it to gcj.
Restart open office.
Create a new database.
Create a table with a date field.
Try to edit the date.
Actual Results: Dates turn into 1/1/70 as soon as you move to the next record.
Expected Results: It should save the date as entered.
Oh, I get this behavior from the 1.9.125 packages. The dates also malfunction
in the new 2.0.0-3.2.1 packages. Annoyingly, the 2.0.0 packages only let you
use gcj, so I don't know if switching to sun's java fixes the problem.
Created attachment 120644 [details]
Database with a table containing a date field.
Here's a file that illustrates the problem. Open it in ooo base: If you use
gcj, all the dates will turn into 1/1/70 and you can't change them. If you use
sun's java, the last date should be different (because I switched to sun's java
and entered it) and you can change the dates.
This bug affects both Date and Time columns, but not Timestamp.
The problem is in the java.util.Calendar implementation in libgcj. The 4.0.x
branch of libgcj has a fix and the trunk should get one (see the related GCC
bug). Depending on what versions ship when, one of these will make it into the
rawhide GCC. The workaround until then is to use Timestamp columns.