toTimeZone doesn't work as expected for renamed zones

[haozhun]

Key information

• Joda-Time version: 2.9.5 or later (data upgraded from 2016d to 2016i in 2.9.5)
• Java version: 8u112 or earlier (data upgrade from 2016f to 2016i in 6u141, 7u131, 8u121)
  • It should also reproduce in 6u131 or earlier, 7u121 or earlier
• To reproduce this, java must be 2016f or earlier. Joda must be 2016g or later.
  • Asia/Rangoon was renamed to Asia/Yangon in 2016g
• This shouldn't matter. But I'm providing them as requested.
  • Result of TimeZone.getDefault(): America/Los_Angeles
  • Result of DateTimeZone.getDefault(): America/Los_Angeles

Problem description and test case

    public static void main(String[] args)
    {
        // This prints Asia/Yangon.
        // Asia/Rangoon was renamed to Asia/Yangon in 2016g.
        DateTimeZone jodaZone = DateTimeZone.forID("Asia/Rangoon");
        System.out.println("joda " + jodaZone);

        // This prints Asia/Rangoon.
        TimeZone javaZone = TimeZone.getTimeZone("Asia/Rangoon");
        System.out.println("java " + javaZone.getID());

        // This prints GMT. Asia/Rangoon is expected.
        // This internally calls j.u.TimeZone.getTimeZone("Asia/Yangon"),
        // which returns GMT, because the zone doesn't exist prior to 2016g.
        TimeZone javaZoneFromJoda = jodaZone.toTimeZone();
        System.out.println("bad  " + javaZoneFromJoda.getID());
    }

I understand this might be very hard to fix, and this project is now in maintenance mode, but I would like to file this issue nevertheless and see what you think. I believe it is a bug that DateTimeZone.forID("Asia/Rangoon").toTimeZone() returns GMT. But I also understand that this is likely a hard bug.

[jodastephen]

I'm happy to review a smallish PR in the area, although I do think it will be tricky to do. I imagine it would require capturing the TZDB data for renames and making them available to the TimeZone conversion code.