Bug 227884 - RHEL-4.4 DST changes required for libgcj
Summary: RHEL-4.4 DST changes required for libgcj
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: gcc
Version: 4.4
Hardware: All
OS: Linux
high
high
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact: David Lawrence
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 227983
TreeView+ depends on / blocked
 
Reported: 2007-02-08 19:27 UTC by Alan Matsuoka
Modified: 2007-11-17 01:14 UTC (History)
4 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2007-03-05 15:07:42 UTC


Attachments (Terms of Use)
libgcj patch for DST timezone changes (20.42 KB, patch)
2007-02-08 19:32 UTC, Alan Matsuoka
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0080 high SHIPPED_LIVE gcc bug fix update 2007-03-05 15:07:16 UTC

Description Alan Matsuoka 2007-02-08 19:27:07 UTC
Description of problem:
(From jakub@redhat.com)

Some customers consider tzdata 2005m changes as "the upcoming DST" changes,
as if tzdata did not change 20 times or so a year.
So guess the question is if gcj has its own tzdata copy like the various
proprietary JVMs have and its own tzdata parser.
I see something what looks like a tzdata file parser in
libjava/java/util/VMTimeZone.java (and
libjava/classpath/vm/reference/java/util/VMTimeZone.java), but am not sure what
exactly it is used for and whether that reads just /etc/localtime, or other
/usr/share/zoneinfo/ files too.
Additionally there seems to be a hardcoded extremely simplified data
in libjava/classpath/java/util/TimeZone.java, apparently generated with
libjava/classpath/scripts/timezones.pl from tzdata and very outdated.

I rerun that script on tzdata2007a to see what the differences would be
and patch is attached.

More importantly, I wonder whether it really has to have a pregenerated
table compiled in, whether that's not something it should create on the fly
by reading /usr/share/zoneinfo/ files.

Version-Release number of selected component (if applicable):

RHEL4.4

Comment 1 Alan Matsuoka 2007-02-08 19:32:20 UTC
Created attachment 147693 [details]
libgcj patch for DST timezone changes

Comment 2 Jakub Jelinek 2007-02-09 10:48:56 UTC
That patch was against trunk and, furthermore, isn't the latest.
There is a newer patch against trunk at
http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00800.html
which I'm going to backport.
Apparently there are several bugs in the TimeZone code, but those need a lot
of work and aren't appropriate for the update now, so guess just the updated
tables should be enough for RHEL4.5.

Comment 3 Jakub Jelinek 2007-02-09 12:14:43 UTC
Simple testcase for QA purposes:

cat > RHBZ227884.java <<\EOF
import java.util.*;

final class RHBZ227884
{
  private static void test (TimeZone t)
  {
    Calendar cal = Calendar.getInstance (t);
    int errors = 0;
    cal.set (Calendar.MILLISECOND, 0);
    cal.set (2007, Calendar.MARCH, 11, 1, 59, 59);
    if (cal.get(Calendar.DST_OFFSET) != 0
        || cal.get(Calendar.ZONE_OFFSET) != -5 * 3600000)
      errors |= 1;
    cal.set (2007, Calendar.MARCH, 11, 3, 00, 00);
    if (cal.get(Calendar.DST_OFFSET) != 3600000
        || cal.get(Calendar.ZONE_OFFSET) != -5 * 3600000)
      errors |= 2;
    cal.set (2007, Calendar.APRIL, 25, 3, 00, 00);
    if (cal.get(Calendar.DST_OFFSET) != 3600000
        || cal.get(Calendar.ZONE_OFFSET) != -5 * 3600000)
      errors |= 4;
    cal.set (2007, Calendar.NOVEMBER, 4, 0, 59, 59);
    if (cal.get(Calendar.DST_OFFSET) != 3600000
        || cal.get(Calendar.ZONE_OFFSET) != -5 * 3600000)
      errors |= 8;
    cal.set (2007, Calendar.NOVEMBER, 4, 2, 00, 00);
    if (cal.get(Calendar.DST_OFFSET) != 0
        || cal.get(Calendar.ZONE_OFFSET) != -5 * 3600000)
      errors |= 16;
    if (errors > 0)
      System.out.println ("FAIL: error bitmask " + errors);
    else
      System.out.println ("PASS: no errors were found");
  }
  public static void main (String[]args)
  {
    test (TimeZone.getTimeZone ("America/New_York"));
    TimeZone t = new SimpleTimeZone (-5000 * 3600, "EST",
                                     Calendar.MARCH, 2, Calendar.SUNDAY,
                                     2000 * 3600,
                                     Calendar.NOVEMBER, 1, Calendar.SUNDAY,
                                     2000 * 3600);
    test (t);
  }
}
EOF
gcj -C RHBZ227884.java
gij RHBZ227884
should print:
PASS: no errors were found
PASS: no errors were found
while with non-fixed libgcj it prints:
FAIL: error bitmask 10
PASS: no errors were found


Comment 4 Jakub Jelinek 2007-02-09 18:48:59 UTC
In gcc-3.4.6-7.

Comment 13 James S. White 2007-03-05 14:51:12 UTC
What am I missing? 

[root@quark ~]# gcj -C RHBZ227884.java 
[root@quark ~]# gij RHBZ227884
FAIL: error bitmask 14
FAIL: error bitmask 14
[root@quark ~]#  gcj --version
gcj (GCC) 3.4.6 20060404 (Red Hat 3.4.6-7)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[root@quark ~]# rpm -qa | egrep "gcc|gcj"
java-1.4.2-gcj-compat-devel-1.4.2.0-27jpp
libgcc-3.4.6-7
gcc-java-3.4.6-7
libgcj-devel-3.4.6-7
libgcj-3.4.6-7
gcc-3.4.6-7
java-1.4.2-gcj-compat-1.4.2.0-27jpp
gcc-c++-3.4.6-7



Comment 14 Red Hat Bugzilla 2007-03-05 15:07:42 UTC
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2007-0080.html


Comment 15 James S. White 2007-03-05 16:18:27 UTC
Is there a way to download these 15 packages in bulk, or do I have to search for
each one manually in the simple package search one at a time for every architecture?

Comment 16 James S. White 2007-03-05 16:31:33 UTC
disregard. I see they have been added to up2date. Apologies.


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