Get best of the week

Y nuevamente sobre "Informaci贸n de zona horaria incorrecta para zonas horarias rusas" [.Net bug, ID: 693286]

Buenas tardes, colegas, me apresuro a compartir el problema que surgi贸 durante la integraci贸n de los servicios Java y .Net. En aras de la claridad, dar茅 un ejemplo: el servicio .Net lee datos del tipo Fecha de la base de datos, los convierte en largos y luego los transfiere al lado del consumidor de Java, donde se crea una instancia completa de java.util.Date desde hace mucho. Todo estar铆a bien hasta que comenz谩ramos a leer los datos hist贸ricos, es decir, los datos antes de la famosa cancelaci贸n de la transici贸n al invierno o al tiempo. El servicio .Net (en la zona horaria rusa) transmite la fecha (o m谩s exactamente forma un largo) para "01/01/2010 13:00:00", y en el lado de Java, se crea una instancia de java.util.Date como "01/01 / 2010 12:00:00 ". 驴De d贸nde viene esta incomprensible diferencia en una hora? Comenzamos a explorar

Entonces, c贸digo Java:
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


Parece que todo es cierto: antes de Medvedev, la diferencia en invierno y verano con Londres era a las 3 en punto, pero despu茅s de Medvedev la diferencia en invierno ya era de 4 horas.

Lo que nos sorprender谩 .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, 隆guau! Es decir, el cambio de zona horaria resulta ser el mismo que "antes" y "despu茅s". Contin煤a buscando en Google y encuentra :

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


Leemos la respuesta:

En resumen, el problema no es causado por un problema con el marco .NET. En cambio, es causado por una actualizaci贸n del sistema operativo que afect贸 a los datos del registro que describen algunas zonas horarias rusas. El trasfondo es que Rusia ha cambiado sus zonas horarias, as铆 como sus compensaciones b谩sicas y las reglas de horario de verano en el mismo a帽o.


驴Y c贸mo es que tengo Windows 7, tengo los 煤ltimos paquetes de servicio y la 煤ltima versi贸n de .Net, y a煤n as铆 el error detectado en 2011 todav铆a no se resuelve? De acuerdo, eso es todo (estoy hablando de aullidos y que todo funciona "como deber铆a" en Java) ... Solo tenga en cuenta este error cuando lea datos no tan hist贸ricos.

More articles:


All Articles