Finally, could you please confirm that is there anything wrong in my code?
Still i did not understand why this test case is failing with new 2020a tz.
 @Test
    public void doesNotFallBackToMinus8InDawsonNovember2020() {
        DateTimeZone timezone = DateTimeZone.forID("America/Dawson");
        Instant dayAfter = new DateTime(2020, 11, 2, 0, 0, timezone)
                .withLaterOffsetAtOverlap()
                .toInstant();
        Instant day = new DateTime(2020, 11, 1, 0, 0, timezone)
                .withLaterOffsetAtOverlap()
                .toInstant();
        long dayAfterOffset = timezone.getOffset(dayAfter.getMillis());
        int dayAfterHours = (int) TimeUnit.MILLISECONDS.toHours(dayAfterOffset);
        long offsetOnDay = timezone.getOffset(day.getMillis());
        int hoursOnDay = (int) TimeUnit.MILLISECONDS.toHours(offsetOnDay);
        assertEquals(hoursOnDay, dayAfterHours);
    }

On Thu, May 21, 2020 at 3:31 AM Paul Eggert <eggert@cs.ucla.edu> wrote:
On 5/20/20 4:32 AM, Sundar Sarma wrote:
> The above test case according to your update (will not fall back on
> 2020-11-01) is correct. But test case is failing.

My guess is that you didn't propagate the data into Java. Java doesn't
use tzdata's TZif files directly; it builds and installs its own copy of
the files and uses that. If Java's copy is obsolete then Java programs
will report obsolete results. For more about this see
<https://data.iana.org/time-zones/tz-link.html> and look for "Oracle Java".

You can test this by running the shell command:

zdump -v -c 2020,2021 America/Dawson

If older tzdata is installed you'll see this:

$ zdump -v -c 2020,2022 America/Dawson
America/Dawson  -9223372036854775808 = NULL
America/Dawson  -9223372036854689408 = NULL
America/Dawson  Sun Mar  8 09:59:59 2020 UTC = Sun Mar  8 01:59:59 2020
PST isdst=0 gmtoff=-28800
America/Dawson  Sun Mar  8 10:00:00 2020 UTC = Sun Mar  8 03:00:00 2020
PDT isdst=1 gmtoff=-25200
America/Dawson  Sun Nov  1 08:59:59 2020 UTC = Sun Nov  1 01:59:59 2020
PDT isdst=1 gmtoff=-25200
America/Dawson  Sun Nov  1 09:00:00 2020 UTC = Sun Nov  1 01:00:00 2020
PST isdst=0 gmtoff=-28800
America/Dawson  Sun Mar 14 09:59:59 2021 UTC = Sun Mar 14 01:59:59 2021
PST isdst=0 gmtoff=-28800
America/Dawson  Sun Mar 14 10:00:00 2021 UTC = Sun Mar 14 03:00:00 2021
PDT isdst=1 gmtoff=-25200
America/Dawson  Sun Nov  7 08:59:59 2021 UTC = Sun Nov  7 01:59:59 2021
PDT isdst=1 gmtoff=-25200
America/Dawson  Sun Nov  7 09:00:00 2021 UTC = Sun Nov  7 01:00:00 2021
PST isdst=0 gmtoff=-28800
America/Dawson  9223372036854689407 = NULL
America/Dawson  9223372036854775807 = NULL

with transitions continuing this fall and next year. In tzdata 2020a
you'll see this:

$ zdump -v -c 2020,2022 America/Dawson
America/Dawson  -9223372036854775808 = NULL
America/Dawson  -9223372036854689408 = NULL
America/Dawson  Sun Mar  8 09:59:59 2020 UT = Sun Mar  8 01:59:59 2020
PST isdst=0 gmtoff=-28800
America/Dawson  Sun Mar  8 10:00:00 2020 UT = Sun Mar  8 03:00:00 2020
MST isdst=0 gmtoff=-25200
America/Dawson  9223372036854689407 = NULL
America/Dawson  9223372036854775807 = NULL

with transitions stopping after March of this year, and Yukon observing
MST now. If you see the latter output then your tzdata is up-to-date; if
Java is reporting incorrect results in this area then the problem has
something to do with the Java installation, which is downstream from us.