Selamat siang, rekan-rekan, saya segera berbagi masalah yang muncul selama integrasi layanan Java dan .Net. Demi kejelasan, saya akan memberikan contoh:. Layanan Net membaca data bertipe Date dari basis data, mengubahnya menjadi panjang, kemudian mentransfernya ke sisi konsumen Java, di mana instance java.util.Date penuh dibuat dari long. Segalanya akan baik-baik saja sampai kita mulai membaca data historis, yaitu data sebelum pembatalan transisi yang terkenal ke musim dingin atau sudah ada. Layanan .Net (di zona waktu Rusia) mentransmisikan tanggal (atau lebih tepatnya membentuk panjang) untuk "01/01/2010 13:00:00", dan di sisi Java, contoh java.util.Date dibuat sebagai "01/01 / 2010 12:00:00. " Dari mana datangnya perbedaan yang tidak dapat dipahami dalam satu jam ?! Kami mulai mengeksplorasi.Jadi, kode 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
Tampaknya semuanya benar: sebelum Medvedev, perbedaan musim dingin dan musim panas dengan London adalah pada jam 3, tetapi setelah Medvedev perbedaan di musim dingin sudah 4 jam.Apa yang akan mengejutkan kami. 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 ?! Artinya, pergeseran zona waktu ternyata sama dengan "sebelum" dan "setelah". Lanjutkan ke google dan temukan :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
Kami membaca jawabannya:Singkatnya, masalah ini bukan disebabkan oleh masalah dengan kerangka NET. Sebaliknya, ini disebabkan oleh pembaruan OS yang memengaruhi data registri yang menjelaskan beberapa zona waktu Rusia. Latar belakangnya adalah bahwa Rusia telah mengubah zona waktu, serta offset dasar dan aturan DST pada tahun yang sama.
Dan bagaimana mungkin saya memiliki Windows 7, saya memiliki semua paket layanan terbaru dan versi terbaru. Net, dan masih ada kesalahan terdeteksi pada tahun 2011 masih belum teratasi ?! Oke, itu saja (saya berbicara tentang lolongan dan bahwa di Jawa semuanya berfungsi "sebagaimana mestinya") ... Hanya memperhitungkan bug ini saat membaca data yang tidak terlalu historis.