Conversion from TimeZone to DateTimeZone fails in Arabic locale

[dalewking]

Our code has some verification code to verify that time conversions work correctly. We are getting crashes in the field apparently when the user's phone is set to Arabic language.

The test case is simply:

TimeZone timeZone = TimeZone.getTimeZone("GMT-0800");
DateTimeZone dateTimeZone = DateTimeZone.forTimeZone(timeZone);

This crashes with:

Fatal Exception: java.lang.IllegalArgumentException: Invalid format: "-٠٨:٠٠" is malformed at "٠٨:٠٠"
       at org.joda.time.format.DateTimeParserBucket.doParseMillis(DateTimeParserBucket.java:187)
       at org.joda.time.format.DateTimeFormatter.parseMillis(DateTimeFormatter.java:780)
       at org.joda.time.DateTimeZone.parseOffset(DateTimeZone.java:612)
       at org.joda.time.DateTimeZone.forTimeZone(DateTimeZone.java:365)

"٠٨:٠٠" is 08:00 in Arabic. Apparently TimeZone internally stores the 0800 using the Arabic numerals, which you fail to parse.

[dlew]

From the stack trace it looks like this is a bug best filed in https://github.com/JodaOrg/joda-time.

[dalewking]

Started to put it there but was scared away by the text saying basically that joda time is no longer necessary due to Java 8

[dlew]

It's still being maintained, especially for bugs like this.

[dalewking]

Moved

[MenoData]

If you want to convert other time zones like zones with a fixed offset or otherwise explicitly specified zone id (as in your test case) then such code can best be rewritten as:

DateTimeZone dtz = DateTimeZone.forID("+08:00");

See also http://www.joda.org/joda-time/apidocs/org/joda/time/DateTimeZone.html#forID-java.lang.String-
for valid inputs of DateTimeZone.forID(...) This link also proves that the observed behaviour is NOT a bug but just a feature limitation. Personally, I think that this limitation is justified because zone identifiers should never be localized so apps have to find other ways to circumvent such problems.

Otherwise, if you want to convert the system time zone then you have really a problem because you don't know the zone id at compile time. One time I have also struggled with such a strange situation where Android does not use stable non-localized identifiers and fortunately solved it in my own time library Time4A, see MenoData/Time4J#463 . However, Joda-Time cannot handle this situation at all.

My recommendation in context of Joda-Time: Try first to parse the identifier yourself. If you find arabic digits then transform it to ASCII western digits before doing the conversion above. I know this is only an incomplete workaround which does not cover all strange scenarios but is at least a partial solution.

[dlew]

For future reference, this is where the bug ended up in joda-time: JodaOrg/joda-time#381

[dalewking]

This has been fixed in 2.9.6 of joda time. Can you update this version of the library to include that?

[dlew]

Since joda-time-android just uses joda-time as a dependency, you can just manually include joda-time 2.9.6 and it'll get used instead.

I'm definitely open to updating the referenced library to 2.9.6 but I don't feel like a new release is necessary for it.