Description of problem: (From jakub) 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): RHEL5
Created attachment 147695 [details] libgcj patch for DST timezone changes
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-0100.html