Incorrect values for at least some zones

[jskeet]

I was trying to investigate an issue reported here: http://mm.icann.org/pipermail/tz/2018-July/026698.html

I decided to implement a tzvalidate dump for Afk.TimeZone, but in doing so I found a problem that it's hard to get past.

The "America/Argentina/Buenos_Aires" time zone seems to get "stuck" for at least some time at 1998-12-31T23:56:15Z. Here's a program to demonstrate:

using System;
using System.Linq;
using Afk.ZoneInfo;

class Program
{
    static void Main(string[] args)
    {
        var zone = TzTimeInfo.GetZones().Single(z => z.Name == "America/Argentina/Buenos_Aires");

        var start = new DateTime(1998, 12, 31, 23, 56, 15, DateTimeKind.Utc);

        for (int i = 0; i < 10; i++)
        {
            Console.WriteLine(zone.ToLocalTime(start.AddTicks(i)).Ticks);
        }
    }
}

The output is:

630507345750000000
630507345750000000
630507345750000000
630507345750000000
630507345750000000
630507345750000000
630507345750000000
630507345750000000
630507345750000000
630507345750000000

That basically suggests that the wall clock stands still for at least those 10 ticks, which shouldn't happen.

I'm going to try to hard-code a workaround for this to start with, but it's not clear whether that will be sufficient.

[jskeet]

I've managed to create a workaround by just skipping a day when I detect this behavior. This allows a tzvalidate file to be generated, that demonstrates a number of other issues. See https://github.com/nodatime/tzvalidate/pull/38 and let me know if you'd like any help running the code or understanding the results.

[LZorglub]

Ticks was not managed, fixed in version 2.2