Get best of the week

Und noch einmal zu "Falsche Zeitzoneninformationen für russische Zeitzonen" [.Net-Fehler, ID: 693286]

Guten Tag, Kollegen, ich beeile mich, das Problem zu teilen, das während der Integration von Java- und .Net-Diensten aufgetreten ist. Aus Gründen der Übersichtlichkeit gebe ich ein Beispiel: Der .Net-Dienst liest Daten vom Typ Datum aus der Datenbank, übersetzt sie in long und übergibt sie dann an die Java-Verbraucherseite, wo aus long eine vollständige java.util.Date-Instanz erstellt wird. Alles wäre in Ordnung, bis wir anfingen, die historischen Daten zu lesen, dh die Daten vor der berühmten Aufhebung des Übergangs in den Winter oder schon dort. Der .Net-Dienst (in der russischen Zeitzone) überträgt das Datum (oder genauer gesagt ein Long) für "01/01/2010 13:00:00", und auf der Java-Seite wird eine java.util.Date-Instanz als "01/01 /" erstellt. 2010 12:00:00. " Woher kommt dieser unverständliche Unterschied in einer Stunde ?! Wir beginnen zu erforschen.

Also, 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


Es scheint, dass alles wahr ist: Vor Medwedew war der Unterschied zwischen Winter und Sommer und London um 3 Uhr, aber nach Medwedew betrug der Unterschied im Winter bereits 4 Stunden.

Was uns überraschen wird .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 ?! Das heißt, die Zeitzonenverschiebung ist dieselbe wie "vorher" und "nachher". Weiter googeln und finden :

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


Wir lesen die Antwort:

Kurz gesagt, das Problem wird nicht durch ein Problem mit dem .NET Framework verursacht. Stattdessen wird es durch ein Betriebssystem-Update verursacht, das Registrierungsdaten beeinflusst, die einige russische Zeitzonen beschreiben. Der Hintergrund ist, dass Russland seine Zeitzonen sowie seine Basisversätze und Sommerzeitregeln alle im selben Jahr geändert hat.


Und wie kommt es, dass ich Windows 7 habe, die neuesten Service Packs und die neueste Version von .Net habe und der 2011 festgestellte Fehler immer noch nicht behoben ist ?! Okay, das ist alles (ich spreche von Heulen und dass in Java alles so funktioniert, wie es sollte) ... Berücksichtigen Sie einfach diesen Fehler, wenn Sie nicht so historische Daten lesen.

More articles:


All Articles