Get best of the week

And again about “Incorrect time zone information for Russian time zones” [.Net bug, ID: 693286]

Good afternoon, colleagues, I hasten to share the problem that arose during the integration of Java and .Net services. For the sake of clarity, I’ll give an example: .Net service reads data of type Date from the database, converts it to long, then transfers it to the Java consumer side, where a full java.util.Date instance is created from long. Everything would be fine until we began to read the historical data, that is, the data before the famous cancellation of the transition to winter-or-already-there-time. The .Net service (in the Russian time-zone) transmits the date (or more accurately forms a long) for "01/01/2010 13:00:00", and on the Java side, an java.util.Date instance is created as "01/01 / 2010 12:00:00. " Where does this incomprehensible difference in an hour come from ?! We begin to explore.

So, Java code:
public class Main {

    public static void main(String[] args) throws ParseException {
        SimpleDateFormat format = new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ss");
        TimeZone tzMoscow = TimeZone.getTimeZone("Europe/Moscow");
        TimeZone tzLondon = TimeZone.getTimeZone("Europe/London");

        System.out.println("Before Medvedev tricks: " + calcTimeZoneShift(tzLondon, tzMoscow, "2010-01-01T13:00:00", format));
        System.out.println("After Medvedev tricks: " + calcTimeZoneShift(tzLondon, tzMoscow, "2013-01-01T13:00:00", format));
    }

    static private long calcTimeZoneShift(TimeZone tz1, TimeZone tz2, String time, SimpleDateFormat format)
            throws ParseException{

        format.setTimeZone(tz1);
        Date date1 = format.parse(time);

        format.setTimeZone(tz2);
        Date date2 = format.parse(time);
        return (date1.getTime() - date2.getTime())/3600000;

    };

}


Output:
Before Medvedev tricks: 3
After Medvedev tricks: 4


It seems that everything is true: before Medvedev, the difference in winter and summer with London was at 3 o’clock, but after Medvedev the difference in winter was already 4 hours.

What will surprise us .Net:

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            
            TimeZoneInfo tzMoscow = TimeZoneInfo.FindSystemTimeZoneById("Russian Standard Time");
            TimeZoneInfo tzLondon = TimeZoneInfo.FindSystemTimeZoneById("GMT Standard Time");
            
            System.Diagnostics.Debug.WriteLine("Before Medvedev tricks: " + calcTimeZoneShift(tzLondon, tzMoscow, "01/01/2010 13:00:00"));
            System.Diagnostics.Debug.WriteLine("After Medvedev tricks: " + calcTimeZoneShift(tzLondon, tzMoscow, "01/01/2013 13:00:00"));

        }

        private static long calcTimeZoneShift(TimeZoneInfo tz1, TimeZoneInfo tz2, String time)
        {
            DateTime date = DateTime.Parse(time);
            DateTime newTime = TimeZoneInfo.ConvertTime(date, tz1, tz2);
            return (newTime.ToFileTimeUtc() - date.ToFileTimeUtc()) / 36000000000;
        }

    }
}


Output:
Before Medevedev tricks: 4
After Medevedev tricks: 4


Mliiin, wow ?! That is, timezone shift turns out to be the same as “before” and “after”. Continue to google it and find :

Incorrect time zone information for Russian time zones by

Type: Bug
ID: 693286
Opened: 10/5/2011 8:18:45 PM
Access Restriction: Public
Moderator Decision: Sent to Engineering Team for consideration

Time zone information for Russian time zones is incorrect. I think this occurs after Russian government disable summer time. Issue occurs then I converting date in the past from UST time zone to one of Russian time zones using routine TimeZoneInfo.ConvertTimeFromUtc
Actual results
UTC 13.06.2010 00:00:00 = Moscow 13.06.2010 5:00:00
UTC 13.12.2010 00:00:00 = Moscow 13.12.2010 4:00:00

Expected results
UTC 13.06.2010 00:00:00 = Moscow 13.06.2010 4:00:00
UTC 13.12.2010 00:00:00 = Moscow 13.12.2010 3:00:00


We read the answer:

In short, the issue is not caused by a problem with the .NET framework. Instead, it is caused by an OS update that affected registry data describing some Russian time zones. The background is that Russia has changed its time zones, as well as their base offsets and DST rules all in the same year.


And how is it that I have Windows 7, I have all the latest service packs and the latest version of .Net, and still the error detected in 2011 is still not resolved ?! Okay, that’s all (I’m talking about howls and that everything works “as it should” in Java) ... Just take this bug into account when reading not so historical data.

More articles:


All Articles