Major issues with joda time on Ubuntu Linux

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Major issues with joda time on Ubuntu Linux

Vladimir Sizikov-3
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Major issues with joda time on Ubuntu Linux

O'Neill, Brian
I'm inclined to uncomment the lines in the systemv tz file. Have you confirmed that this works? That is, build a new version of Joda-time and try it out?

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Vladimir Sizikov
Sent: Tuesday, July 08, 2008 12:15 PM
To: [hidden email]
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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Major issues with joda time on Ubuntu Linux

Vladimir Sizikov-3
Hi Brian,

Thanks for the quick response!

On Tue, Jul 8, 2008 at 9:28 PM, O'Neill, Brian <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Vladimir Sizikov
> Sent: Tuesday, July 08, 2008 12:15 PM
> To: [hidden email]
> 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
> [hidden email]
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Major issues with joda time on Ubuntu Linux

Vladimir Sizikov-3
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 <[hidden email]> wrote:

> Hi Brian,
>
> Thanks for the quick response!
>
> On Tue, Jul 8, 2008 at 9:28 PM, O'Neill, Brian <[hidden email]> 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: [hidden email] [mailto:[hidden email]] On Behalf Of Vladimir Sizikov
>> Sent: Tuesday, July 08, 2008 12:15 PM
>> To: [hidden email]
>> 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
>> [hidden email]
>> 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
>> [hidden email]
>> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Major issues with joda time on Ubuntu Linux

P. Hill & E. Goodall
In reply to this post by Vladimir Sizikov-3
There is nothing "proper" about converting MET to Middle European Time
or to MiddleEast Time (even though the second one is less common than
the first).  The general problem is that the three letter abbreviations
are not unique (and need not be), so adding additional special case
fallback rules is a difficult to support solution.  The tzdata folks can
do a much better job of working out all known values than any Java
package ever could.

Hopefully, Ubuntu will be updated to correct the installation of
the tzdata
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/246732

Thanks for following up on this and pointing it out to the Ubuntu folks.

-Paul

Vladimir Sizikov wrote:
> 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.
>

-------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Major issues with joda time on Ubuntu Linux

Vladimir Sizikov-3
Hi,

On Mon, Jul 14, 2008 at 9:42 AM, P.Hill & E. Goodall
<[hidden email]> wrote:
> There is nothing "proper" about converting MET to Middle European Time
> or to MiddleEast Time (even though the second one is less common than
> the first).

By "proper" I meant in sync with Olson TZ database. And in Olson, MET
is officially recognized and it means Middle European Time.

Java, as well as Linux, and pretty much everybody else, are now fully
use/support Olson database, and joda-time behaves incompatibly there,
converting MET to MiddleEast time.

>  The general problem is that the three letter abbreviations
> are not unique (and need not be), so adding additional special case
> fallback rules is a difficult to support solution.

Indeed. But it is already there, an additional special case for MET in
joda-time that converts it to MiddleEast Time.

Also, I might imagine that different projects have different
priorities. For some, they really want the old compatibility with
ancient JDK versions (where MET means MidleEast Time). Others might
really want to be compatible to Olson as much as possible.

Hence was the suggestion to allow (essentially, to open to joda time
clients) the ability to customize those "custom" conversion rules.
Currently, they are hardcoded in joda time and very hard to
adjust/change.

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Major issues with joda time on Ubuntu Linux

Brian S O'Neill
To my knowledge, Joda-Time has no special case for MET. It just uses the
Olson database, which also provides rules for backwards compatibility.
Here's the only data I found which refers to "MET":

# These are for backward compatibility with older versions.

# Zone    NAME        GMTOFF    RULES    FORMAT    [UNTIL]
Zone    WET        0:00    EU    WE%sT
Zone    CET        1:00    C-Eur    CE%sT
Zone    MET        1:00    C-Eur    ME%sT
Zone    EET        2:00    EU    EE%sT

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.

String name = DateTimeZone.forID("MET").getName(System.currentTimeMillis())

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. You can use the raw
Provider interface to have complete control over how zones work. All the
provder classes that Joda-Time uses by default are available in the
public API, and you can use them however you like. The
DateTimeZoneBuilder class allows you to create complex time zone
definitions, and this is the same class used to build all the time zones
already.

If you wish to start customizing from the Olson database, you can simply
alter these files as provided in the Joda-Time source distribution and
create your own build. You may also wish to invoke the ZoneInfoCompiler
class directly, and use the results in your own Provider.

Vladimir Sizikov wrote:

> Hi,
>
> On Mon, Jul 14, 2008 at 9:42 AM, P.Hill & E. Goodall
> <[hidden email]> wrote:
>  
>> There is nothing "proper" about converting MET to Middle European Time
>> or to MiddleEast Time (even though the second one is less common than
>> the first).
>>    
>
> By "proper" I meant in sync with Olson TZ database. And in Olson, MET
> is officially recognized and it means Middle European Time.
>
> Java, as well as Linux, and pretty much everybody else, are now fully
> use/support Olson database, and joda-time behaves incompatibly there,
> converting MET to MiddleEast time.
>
>  
>>  The general problem is that the three letter abbreviations
>> are not unique (and need not be), so adding additional special case
>> fallback rules is a difficult to support solution.
>>    
>
> Indeed. But it is already there, an additional special case for MET in
> joda-time that converts it to MiddleEast Time.
>
> Also, I might imagine that different projects have different
> priorities. For some, they really want the old compatibility with
> ancient JDK versions (where MET means MidleEast Time). Others might
> really want to be compatible to Olson as much as possible.
>
> Hence was the suggestion to allow (essentially, to open to joda time
> clients) the ability to customize those "custom" conversion rules.
> Currently, they are hardcoded in joda time and very hard to
> adjust/change.
>
> 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
> [hidden email]
> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Major issues with joda time on Ubuntu Linux

Vladimir Sizikov-3
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 <[hidden email]> 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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Major issues with joda time on Ubuntu Linux

O'Neill, Brian
Ugh, I forgot about this. I need to dig up the source of this conversion table. It might be necessary to have a more intelligent mapping. Have multiple mappings and choose by comparing the standard offset of the JDK time zone to the Joda one.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Vladimir Sizikov
Sent: Monday, July 14, 2008 01:19 PM
To: Discussion of the Joda project
Subject: Re: [Joda-interest] Major issues with joda time on Ubuntu Linux

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 <[hidden email]> 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
[hidden email]
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/joda-interest
Loading...