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:
1. Joda is using Locale.getDefault() to determine the user's default locale for formatting.
2. Java is now using Locale.getDefault(Locale.Category.FORMAT) to determine the user's default locale for formatting.
3. 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:
1. 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.
2. 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.