Hi, Some more info. It turned out that the strange behavior of JDK that reports those outdated SystemV/PST8PDT-like zones is due to bug in Ubuntu 7.10.
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/246732 Thanks, --Vladimir On Tue, Jul 8, 2008 at 9:50 PM, Vladimir Sizikov <[EMAIL PROTECTED]> wrote: > Hi Brian, > > Thanks for the quick response! > > On Tue, Jul 8, 2008 at 9:28 PM, O'Neill, Brian <[EMAIL PROTECTED]> wrote: >> I'm inclined to uncomment the lines in the systemv tz file. > > The downside of this method is that those changes will need to be > merged every time the TZ info updated from the upstream, right? > > Also, it would be really useful at times to have the access and the > possibility to update the conversion rules programmatically (e.g., to > have an access to cZoneIdConversion map from DateTimeZone). That way, > JRuby could adjust the conversion rules when neccessary. > > E.g., there is another case for that. 'MET' time zone. Joda Time > converts it to "Asia/Tehran", while in recent JDKs it is (properly) > Middle European Time. > > It would be great to be able to adjust those things without > recompiling/rebundling/forking Joda Time. > >> Have you confirmed that this works? That is, build a new version of >> Joda-time and try it out? > > It seems that as soon as I uncomment any line in systemv file, like this: > > Zone SystemV/PST8PDT -8:00 SystemV P%sT > > the build will fail: > [java] Writing Etc/GMT+12 > [java] Exception in thread "main" > org.joda.time.IllegalFieldValueException: Value 292278995 for year > must be in the range [-292275054,292278993] > [java] at > org.joda.time.field.FieldUtils.verifyValueBounds(FieldUtils.java:215) > [java] at > org.joda.time.chrono.BasicYearDateTimeField.set(BasicYearDateTimeField.java:82) > [java] at > org.joda.time.chrono.BasicYearDateTimeField.add(BasicYearDateTimeField.java:63) > [java] at > org.joda.time.tz.DateTimeZoneBuilder$OfYear.next(DateTimeZoneBuilder.java:574) > [java] at > org.joda.time.tz.DateTimeZoneBuilder$Recurrence.next(DateTimeZoneBuilder.java:760) > [java] at > org.joda.time.tz.DateTimeZoneBuilder$Rule.next(DateTimeZoneBuilder.java:862) > [java] at > org.joda.time.tz.DateTimeZoneBuilder$RuleSet.nextTransition(DateTimeZoneBuilder.java:1092) > [java] at > org.joda.time.tz.DateTimeZoneBuilder$RuleSet.firstTransition(DateTimeZoneBuilder.java:1028) > [java] at > org.joda.time.tz.DateTimeZoneBuilder.toDateTimeZone(DateTimeZoneBuilder.java:350) > [java] at > org.joda.time.tz.ZoneInfoCompiler.compile(ZoneInfoCompiler.java:374) > [java] at > org.joda.time.tz.ZoneInfoCompiler.main(ZoneInfoCompiler.java:116) > > Thanks, > --Vladimir > >> >> -----Original Message----- >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Vladimir >> Sizikov >> Sent: Tuesday, July 08, 2008 12:15 PM >> To: joda-interest@lists.sourceforge.net >> Subject: [Joda-interest] Major issues with joda time on Ubuntu Linux >> >> Hi, >> >> I'm currently investigating a couple of JRuby issues related to Time (and >> JRuby uses joda-time internally, with much satisfaction, I might add). >> >> The particular issue is here: >> http://jira.codehaus.org/browse/JRUBY-2541 >> >> Essentially, it boils down to a fact that Ubuntu users with US timezones end >> up getting the UTC as their default time zone rather than proper ones. >> >> It all starts with JDK (JDK 6 or openJDK), which returns "SystemV/PST8PDT" >> default timezone for those who are on Pacific Coast and "SystemV/EST5EDT" >> for those who are on East Coast. >> >> And, since JodaTime uses: >> forTimeZone(TimeZone.getDefault()) >> >> it can't really understand such weird zones properly, and we end up with >> UTC. Pretty bad. :( >> >> Here's a small jruby snippet that shows the problem: >> jruby -rjava -e "p org.joda.time.DateTimeZone.getDefault.getID; p >> java.util.TimeZone.getDefault.getID" >> >> "UTC" >> "SystemV/PST8PDT" >> >> We basically just print out the IDs obtained from getDefault() methods from >> JDK and JodaTime. >> >> It would be really, really nice to have this fixed. So far, I see a couple >> of ways to do that: >> 1. In DateTimeZone.getConvertedId, add those SystemV conversions, so that >> "SystemV/PST8PDT" --> "PST8PDT", which is understood by JodaTime. >> >> 2. Uncomment SystemV/* definitions in tz's systemv file. >> >> Thanks, >> --Vladimir >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, along >> with a healthy diet, reduces your potential for chronic lameness and >> boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Joda-interest mailing list >> Joda-interest@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/joda-interest >> >> ------------------------------------------------------------------------- >> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! >> Studies have shown that voting for your favorite open source project, >> along with a healthy diet, reduces your potential for chronic lameness >> and boredom. Vote Now at http://www.sourceforge.net/community/cca08 >> _______________________________________________ >> Joda-interest mailing list >> Joda-interest@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/joda-interest >> > ------------------------------------------------------------------------- Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW! Studies have shown that voting for your favorite open source project, along with a healthy diet, reduces your potential for chronic lameness and boredom. Vote Now at http://www.sourceforge.net/community/cca08 _______________________________________________ Joda-interest mailing list Joda-interest@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/joda-interest
