Hi Brian,
Thanks for the responses and lots of useful info!
My comments below.
On Mon, Jul 14, 2008 at 4:50 PM, Brian S O'Neill <[EMAIL PROTECTED]> wrote:
> To my knowledge, Joda-Time has no special case for MET. It just uses the
> Olson database, which also provides rules for backwards compatibility.
> A short test program yields "Middle Europe Summer Time". It appears that
> Joda-Time is in fact correct. It is not reporting MiddleEast time as
> claimed.
DateTimeZone.getDefault() uses:
forTimeZone(TimeZone.getDefault());
and when JDK's TimeZone.getDefault() returns MET timezone (which it
does for many European users), Joda-Time's forTimeZone() method
converts it to MiddleEast timezone, explicitly in getConvertedId()
method:
map.put("MET", "Asia/Tehran");
Here's the URL to the code: http://bit.ly/SLf83
This causes JRuby's misbehavior in case when the default timezone is
MET (european one).
See here: http://jira.codehaus.org/browse/JRUBY-2759
> As for customizing the rules, Joda-Time has always had a means to do so.
> The DateTimeZone class has static methods for setting the default rule
> and name provider, each with security checks.
Yep, I considered this route too. But for this particular use case, we
don't really need any new provider, all we need is (in
getConvertedId()) to disable that (outdated) conversion of MET to
"Asia/Tehran", and (possibly) to enable conversion of SystemV/PST5PDT
and similar ones to "PST5PDT" ,etc.
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
