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): openoffice.org-core-1.9.125-1.1.0.fc4, libgcj-4.0.1-4.fc4 How reproducible: Always 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. Additional info:
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.