Bug 172305 - Dates become 1/1/70 using OpenOffice Base files with gcj
Dates become 1/1/70 using OpenOffice Base files with gcj
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: hsqldb (Show other bugs)
4
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Archit Shah
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-11-02 11:01 EST by Garrett Mitchener
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-22 15:17:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Database with a table containing a date field. (7.69 KB, application/vnd.oasis.opendocument.database)
2005-11-02 11:05 EST, Garrett Mitchener
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 24860 None None None Never

  None (edit)
Description Garrett Mitchener 2005-11-02 11:01:33 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):
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:
Comment 1 Garrett Mitchener 2005-11-02 11:03:19 EST
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.
Comment 2 Garrett Mitchener 2005-11-02 11:05:34 EST
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.
Comment 3 Archit Shah 2005-11-07 15:11:56 EST
This bug affects both Date and Time columns, but not Timestamp.
Comment 4 Archit Shah 2005-11-14 15:20:12 EST
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.

Note You need to log in before you can comment on or make changes to this bug.