Incorrect handling of IANA time zone data

[jskeet]

Key information

• Joda-Time version: 2.9.3
• Result of TimeZone.getDefault(): sun.util.calendar.ZoneInfo[id="Europe/London", [...]]
• Result of DateTimeZone.getDefault(): Europe/London

Problem description

My tzvalidate project aims to make it easy to validate that code intepreting the IANA time zone data all does it in the same way. Joda Time appears to have some discrepancies. (Without looking into the code, it's hard to guess how many code changes would be required.)

Test case

As a single example, using the 2016d data release, Joda Time claims America/Argentina/Catamarca had a transition at 1999-10-03T04:00:00Z; I believe this transition should be at 1999-10-03T03:00:00Z. (This was just a change from standard to daylight, but without any overall offset change.

http://www.timeanddate.com/time/zone/argentina/catamarca confirms that this would have been at 3am UTC (midnight local)

Sample code:

import java.io.*;
import java.util.*;
import org.joda.time.*;
import org.joda.time.tz.*;

public class Test
{
    public static void main(String[] args) throws Exception
    {
        ZoneInfoCompiler compiler = new ZoneInfoCompiler();
        File[] files = { new File("southamerica") }; // From 2016d
        Map<String, DateTimeZone> zones = compiler.compile(null, files);
        DateTimeZone zone = zones.get("America/Argentina/Catamarca");

        DateTime midJune = new DateTime(1999, 6, 15, 0, 0, 0, DateTimeZone.UTC);
        long millis = zone.nextTransition(midJune.getMillis());
        DateTime transition = new DateTime(millis, DateTimeZone.UTC);
        System.out.println(transition);
    }
}

Expected output: 1999-10-03T03:00:00.000Z
Actual output: 1999-10-03T04:00:00.000Z

I'm very happy to provide the full tzvalidate files for 2016d - the one I'm treating as "canonical" agrees with both zic and Noda Time, as well as a third party implementation. I haven't attached the files here as they're rather large.

[jodastephen]

Thanks for raising this. I'm just acknowledging this is probably wrong, but I'm unlikely to have the time to look into why. The work on establishing a standard format for validation seems like a great idea though - just wish it had existed 10 years ago!

[jskeet]

I was surprised to find it didn't exist, too :) I haven't yet filed bugs for java.util.TimeZone or java.time.ZoneId, though they had issues too, last I looked - if there are any particular tips on filing JRE bugs, please drop me a line... otherwise I'll wait until I've got enough time/patience to see what's required.

[jodastephen]

Filing a JDK bug is nigh on impossible. However, I have the rights to JIRA. So if you send me the details I can post it for you!

[jskeet]

Wonderful - thanks very much, will follow up by email.

[jodastephen]

Dhaka is out by a millisecond, but there was probably a deliberate reason for that. Anyway, I've fixed everything else. Thanks for the tool.

[gsmet]

Hi @jodastephen!

We are currently having issues with Elasticsearch (2.4.1 and 5, it's a regression from previous versions) due to this bug (see elastic/elasticsearch#20911) and it would be nice to get it fixed in a release.

Any plan for the 2.9.5 release?

Thanks for your feedback!