1

If I run the following code in Java 8:-

package au.com.tt.agora.debug.web;

import java.util.TimeZone;

import org.joda.time.DateTimeZone;
import org.joda.time.LocalDate;

public class Test
{

    public static void main(String[] args)
    {
        String newDate = new LocalDate().toString("ddMMMyy");
        System.out.println(newDate);
        System.out.println(TimeZone.getDefault());
        System.out.println(DateTimeZone.getDefault());
    }

}

I get this result:-

14Apr20
sun.util.calendar.ZoneInfo[id="Australia/Sydney",offset=36000000,dstSavings=3600000,useDaylight=true,transitions=142,lastRule=java.util.SimpleTimeZone[id=Australia/Sydney,offset=36000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=9,startDay=1,startDayOfWeek=1,startTime=7200000,startTimeMode=1,endMode=3,endMonth=3,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=1]]
Australia/Sydney

I run the same code in Java 11 I get the following result:-

14Apr.20
sun.util.calendar.ZoneInfo[id="Australia/Sydney",offset=36000000,dstSavings=3600000,useDaylight=true,transitions=142,lastRule=java.util.SimpleTimeZone[id=Australia/Sydney,offset=36000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=9,startDay=1,startDayOfWeek=1,startTime=7200000,startTimeMode=1,endMode=3,endMonth=3,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=1]]
Australia/Sydney

Note the . between Apr and 20. Is this a bug or a new feature of Joda date time in Java 11?

UPDATE I am using Joda v2.10.5. Also, this code:-

package au.com.tt.agora.debug.web;

import java.time.format.DateTimeFormatter; import java.util.TimeZone;

import org.joda.time.DateTimeZone; import org.joda.time.LocalDate;

public class Test
{

    public static void main(String[] args)
    {
        LocalDate joda = new LocalDate();
        java.time.LocalDate date = java.time.LocalDate.of(joda.getYear(), joda.getMonthOfYear(), joda.getDayOfMonth());
        System.out.println(date.format(DateTimeFormatter.ofPattern("ddMMMyy")));
        System.out.println(TimeZone.getDefault());
        System.out.println(DateTimeZone.getDefault());
    }

}

produces the same result for the date. I am using Java 11.0.6 on Windows.

UPDATE 2 Turns out it is a locale problem. Between Java 8 and Java 11 there was a change in the way certain locales (en_AU and en_CA specifically) deal with dates. See here for more details:-

https://bugs.openjdk.java.net/browse/JDK-8211750

Have to work out what I have to do in this case, but at least I understand the problem.

Naman
  • 27,789
  • 26
  • 218
  • 353
user1545858
  • 725
  • 4
  • 21
  • What is your `name: 'joda-time'` version ? i don't have any issue with `jdk-11` and with joda time version `version: '2.10.5'` – Ryuzaki L Apr 14 '20 at 02:02
  • @Deadpool I have updated the ticket. The problem applies to Java LocalDate as well. – user1545858 Apr 14 '20 at 02:30
  • It’s CLDR. Does this answer your question? [SimpleDateFormat .format() gives different results in Java8 vs. Java11 \[duplicate\]](https://stackoverflow.com/questions/57049592/simpledateformat-format-gives-different-results-in-java8-vs-java11). Or [this](https://stackoverflow.com/questions/56814020/parsing-time-with-localtime) or [this](https://stackoverflow.com/questions/46244724/jdk-dateformater-parsing-dayofweek-in-german-locale-java8-vs-java9)? – Ole V.V. Apr 14 '20 at 04:40
  • Thanks @OleV.V. I found those issues after I realised what the actual problem was. – user1545858 Apr 14 '20 at 04:54

1 Answers1

2

Turns out it is a locale problem. Between Java 8 and Java 11 there was a change in the way certain locales (en_AU and en_CA as examples) deal with dates. See here for more details:-

https://bugs.openjdk.java.net/browse/JDK-8211750

Have to work out what I have to do in this case, but at least I understand the problem

user1545858
  • 725
  • 4
  • 21
  • 1
    Good research. However, the time zone code in your example is irrelevant and just confuses. Going with the JRE start parameter `-Djava.locale.providers=COMPAT` would be an option. Or even better: You will get accustomed to the changed localization style because the underlying CLDR text resources are not set in stone, and you should not base any important logic on textual styling. – Meno Hochschild Apr 14 '20 at 04:07