This bug shows up if you run against Java 7. Here's a simple test, just using JUnit because it's handy:
@Test
public void testJodaLocale() throws Exception {
System.out.println("Java: " + DateFormat.getDateTimeInstance(DateFormat.LONG, DateFormat.LONG).format(new Date()));
System.out.println("Joda: " + DateTimeFormat.longDateTime().print(DateTime.now()));
}
For me, this outputs:
Java: 21 November 2011 12:44:07 PM
Joda: November 21, 2011 12:44:07 PM EST
Here's what's going on:
- Joda is using Locale.getDefault() to determine the user's default locale for formatting.
- Java is now using Locale.getDefault(Locale.Category.FORMAT) to determine the user's default locale for formatting.
- My locale settings happen to have two different values in there, although I don't know why this is (getDefault() is en_US but getDefault(FORMAT) is en_AU.)
Although it is not Joda's fault and I can't see any way it could have been predicted either, this bug is particularly annoying because:
- Now every time someone calls DateTimeFormat.anything(), they have to add on a withLocale(...) call to set the locale to the actual default locale for formatting dates.
- It has caused a change in our test output without changing a single line of our own code, because the new default for Locale.getDefault() in Java 7 is different to the old default. (!!)
The only approach I can think of is to write reflection code to get the FORMAT locale on Java 7. There is already some code in DateTimeUtils that handles Java 5 vs 6 on locales.
If you'd like to code it up, please fork on GitHub. I'm unlikely to get to it myself I suspect...
(See http://joconner.com/category/java/ for more details)
See also http://stackoverflow.com/questions/7107972/java-7-default-locale and http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7073906
I'm trying to find out from Oracle whats going on, as this looks like a bug at their end.