Bunları neden iki kez çıkarmak (1927'de) garip bir sonuç veriyor?

Aşağıdaki programı, 1 saniye arayla iki tarih dizesini ayrıştıran ve karşılaştıran aşağıdaki programı çalıştırırsam:

public static void main(String[] args) throws ParseException {
    SimpleDateFormat sf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss");  
    String str3 = "1927-12-31 23:54:07";  
    String str4 = "1927-12-31 23:54:08";  
    Date sDt3 = sf.parse(str3);  
    Date sDt4 = sf.parse(str4);  
    long ld3 = sDt3.getTime() /1000;  
    long ld4 = sDt4.getTime() /1000;
    System.out.println(ld4-ld3);
}

Çıktı:

353

Neden olduğu ld4-ld3değil 1(ı zamanlarda bir saniyelik farktan beklediğiniz gibi), ancak 353?

Tarihleri ​​1 saniye sonraya değiştirirsem:

String str3 = "1927-12-31 23:54:08";  
String str4 = "1927-12-31 23:54:09";  

O ld4-ld3zaman olacak 1.

Java sürümü:

java version "1.6.0_22"
Java(TM) SE Runtime Environment (build 1.6.0_22-b04)
Dynamic Code Evolution Client VM (build 0.2-b02-internal, 19.0-b04-internal, mixed mode)

Timezone(`TimeZone.getDefault()`):

sun.util.calendar.ZoneInfo[id="Asia/Shanghai",
offset=28800000,dstSavings=0,
useDaylight=false,
transitions=19,
lastRule=null]

Locale(Locale.getDefault()): zh_CN

31 Aralık'ta Şanghay'da bir saat dilimi değişikliği.

Şangay'daki 1927 detayları için bu sayfaya bakın . Temel olarak 1927'nin sonunda gece yarısı, saatler 5 dakika 52 saniye geri gitti. Yani "1927/12/31 23:54:08" aslında iki kez oldu ve Java olarak yeniden ayrıştırma gibi görünüyor daha sonra yerel tarih / zaman mümkün anlık - dolayısıyla fark.

Sadece garip ve harika zaman dilimleri dünyasında başka bir bölüm.

EDIT: Basın durdurun! Tarih değişiklikleri ...

Orijinal soru, TZDB'nin 2013a sürümü ile yeniden oluşturulduğunda, aynı davranışı göstermeyecektir . 2013a'da sonuç, geçiş süresi 23:54:08 yerine 23:54:03 olacak şekilde 358 saniye olacaktır.

Bunu sadece fark ettim çünkü Noda Time'da, birim testler şeklinde böyle sorular topluyorum ... Test şimdi değişti, ama göstermeye devam ediyor - geçmiş veriler bile güvenli değil.

EDIT: Tarih yeniden değişti ...

TZDB 2014f, değişim zamanı 1900-12-31 taşındı ve (arasındaki zaman yüzden şimdi sadece 343 saniye değişikliğidir tve t+1344 saniyedir, ne demek istediğimi görürseniz).

DÜZENLEME: 1900'de bir geçişle ilgili bir soruyu yanıtlamak için ... Java saat dilimi uygulaması, tüm saat dilimlerini 1900 UTC'nin başlangıcından önce herhangi bir an için standart saatlerinde olduğu gibi ele alıyor gibi görünüyor :

import java.util.TimeZone;

public class Test {
    public static void main(String[] args) throws Exception {
        long startOf1900Utc = -2208988800000L;
        for (String id : TimeZone.getAvailableIDs()) {
            TimeZone zone = TimeZone.getTimeZone(id);
            if (zone.getRawOffset() != zone.getOffset(startOf1900Utc - 1)) {
                System.out.println(id);
            }
        }
    }
}

Yukarıdaki kod Windows makinemde çıktı üretmiyor. Dolayısıyla, 1900'ün başında standart olandan başka herhangi bir ofseti olan herhangi bir saat dilimi bunu bir geçiş olarak sayar. TZDB'nin kendisinden daha önceki bazı veriler vardır ve "sabit" bir standart zaman ( getRawOffsetgeçerli bir kavram olduğu varsayılır) fikrine dayanmaz, bu nedenle diğer kütüphanelerin bu yapay geçişi tanıtması gerekmez.

Yerel bir zaman süreksizliği ile karşılaştınız :

Yerel standart saat 1: Pazar günü ulaşmak üzereyken, 1 Ocak 1928, 00:00:00 saatler, saat 01:05:52 saat, Cumartesi, 31. Aralık 1927, 23:54:08 yerine yerel standart saat

Bu özellikle garip değildir ve zaman dilimleri politik veya idari eylemler nedeniyle değiştirildiği veya değiştiği için hemen hemen her yerde gerçekleşmiştir.

Bu garipliğin ahlakı:

• Tarihleri ​​ve saatleri UTC'de mümkün olan her yerde kullanın.
• UTC'de bir tarih veya saat görüntüleyemiyorsanız, her zaman saat dilimini belirtin.
• UTC'de bir giriş tarihi / saati gerektiremiyorsanız, açıkça belirtilen bir saat dilimi isteyin.

Süreyi uzatırken UTC'ye dönmeli ve sonra eklemeli ya da çıkarmalısınız. Yerel saati yalnızca görüntüleme için kullanın.

Bu şekilde saatlerin veya dakikaların iki kez meydana geldiği dönemlerde yürüyebileceksiniz.

UTC'ye dönüştürdüyseniz, her saniyeyi ekleyin ve görüntüleme için yerel saate dönüştürün. Sen 23:54:08 üzerinden gideceğini LMT'de - 11:59:59 pm LMT ve ardından 11:54:08 CST - 11:59:59 CST.

Her tarihi dönüştürmek yerine aşağıdaki kodu kullanabilirsiniz:

long difference = (sDt4.getTime() - sDt3.getTime()) / 1000;
System.out.println(difference);

Ve sonra sonucun:

1

Söylediğim için üzgünüm, ama zaman süreksizliği biraz

JDK 6 iki yıl önce ve JDK 7'de son 25 güncellemesinde .

Öğrenilmesi gereken dersler: Belki gösterim dışında, UTC dışındaki zamanlardan kaçının.

Başkaları tarafından açıklandığı gibi, orada bir süreksizlik var. Orada iki olası zaman dilimi uzaklıklar içindir 1927-12-31 23:54:08de Asia/Shanghai, ama sadece bir için ofset 1927-12-31 23:54:07. Yani, hangi ofseti kullanıldığına bağlı olarak, ya bir saniye fark ya da 5 dakika ve 53 saniye fark vardır.

Ofsetlerin bu hafif kayması, alışkın olduğumuz olağan bir saatlik yaz saati (yaz saati) yerine, sorunu biraz gizliyor.

Saat dilimi veritabanının 2013a güncellemesinin bu süreksizliği birkaç saniye önce taşıdığını, ancak etkinin hala gözlemlenebilir olacağını unutmayın.

java.timeJava 8'deki yeni paket bunu daha açık bir şekilde görmenizi sağlar ve bunu ele almak için araçlar sağlar. Verilen:

DateTimeFormatterBuilder dtfb = new DateTimeFormatterBuilder();
dtfb.append(DateTimeFormatter.ISO_LOCAL_DATE);
dtfb.appendLiteral(' ');
dtfb.append(DateTimeFormatter.ISO_LOCAL_TIME);
DateTimeFormatter dtf = dtfb.toFormatter();
ZoneId shanghai = ZoneId.of("Asia/Shanghai");

String str3 = "1927-12-31 23:54:07";  
String str4 = "1927-12-31 23:54:08";  

ZonedDateTime zdt3 = LocalDateTime.parse(str3, dtf).atZone(shanghai);
ZonedDateTime zdt4 = LocalDateTime.parse(str4, dtf).atZone(shanghai);

Duration durationAtEarlierOffset = Duration.between(zdt3.withEarlierOffsetAtOverlap(), zdt4.withEarlierOffsetAtOverlap());

Duration durationAtLaterOffset = Duration.between(zdt3.withLaterOffsetAtOverlap(), zdt4.withLaterOffsetAtOverlap());

O durationAtEarlierOffsetzaman bir saniye, durationAtLaterOffsetbeş dakika 53 saniye olacak.

Ayrıca, bu iki ofset aynıdır:

// Both have offsets +08:05:52
ZoneOffset zo3Earlier = zdt3.withEarlierOffsetAtOverlap().getOffset();
ZoneOffset zo3Later = zdt3.withLaterOffsetAtOverlap().getOffset();

Ancak bu ikisi farklı:

// +08:05:52
ZoneOffset zo4Earlier = zdt4.withEarlierOffsetAtOverlap().getOffset();

// +08:00
ZoneOffset zo4Later = zdt4.withLaterOffsetAtOverlap().getOffset();

Bununla 1927-12-31 23:59:59birlikte aynı sorunu görebilirsiniz 1928-01-01 00:00:00, ancak bu durumda, daha uzun sapma üreten erken ofsettir ve iki olası ofsete sahip olan önceki tarihtir.

Buna yaklaşmanın bir başka yolu da bir geçiş olup olmadığını kontrol etmektir. Bunu şu şekilde yapabiliriz:

// Null
ZoneOffsetTransition zot3 = shanghai.getRules().getTransition(ld3.toLocalDateTime);

// An overlap transition
ZoneOffsetTransition zot4 = shanghai.getRules().getTransition(ld3.toLocalDateTime);

Kullanarak - Birden fazla geçerli olduğunu tarih / saat veya tarih / saat o bölge kimliği için geçerli olmayan bir boşluk için ofset olduğu yerde geçiş bir örtüşme olup olmadığını kontrol edebilirsiniz isOverlap()ve isGap()ilgili yöntemler zot4.

Umarım bu, Java 8 yaygın olarak kullanılabilir hale geldiğinde veya JSR 310 backport'u benimseyen Java 7 kullananlara bu tür bir sorunu çözme konusunda yardımcı olur.

IMHO, Java'daki yaygın, örtük yerelleştirme, en büyük tasarım kusurudur. Kullanıcı arayüzleri için düşünülmüş olabilir, ancak açıkçası, programcıların tam olarak hedef kitlesi olmadığı için yerelleştirmeyi temel olarak göz ardı edebileceğiniz bazı IDE'ler dışında bugün kullanıcı arayüzleri için Java'yı gerçekten kullanan kullanıcılar. Bunu (özellikle Linux sunucularında) şu şekilde düzeltebilirsiniz:

• dışa aktar LC_ALL = C TZ = UTC
• sistem saatinizi UTC olarak ayarlayın
• kesinlikle gerekli olmadıkça asla yerelleştirilmiş uygulamaları kullanmayın (yani yalnızca gösterim için)

To Java Community Process üyeleri Ben tavsiye:

• yerelleştirilmiş yöntemleri varsayılan yapmak, ancak kullanıcının açıkça yerelleştirme istemesini gerektirir.
• UTF-8 / UTC'yi FIXED varsayılanı olarak kullanın, çünkü bu sadece bugünün varsayılanı. Bunun gibi iplik üretmek istiyorsanız, başka bir şey yapmak için hiçbir neden yoktur.

Yani, hadi, küresel statik değişkenler bir anti-OO paterni değil mi? Başka hiçbir şey, bazı temel çevre değişkenleri tarafından verilen yaygın temerrütler değildir .......

Diğerlerinin söylediği gibi, 1927'de Şanghay'da bir zaman değişikliği.

O iken 23:54:07Shanghai, yerel standart saat, ama 5 dakika ve 52 saniye sonra, o ertesi gün döndü 00:00:00, ardından yerel standart saat geri değişti 23:54:08. Bu yüzden iki kez arasındaki fark, beklediğiniz gibi 1 saniye değil 343 saniyedir.

Zaman, ABD gibi başka yerlerde de berbat olabilir. ABD'de Yaz Saati Uygulaması var. Yaz Saati Uygulaması başladığında saat 1 saat ileri gider. Ancak bir süre sonra Yaz Saati uygulaması sona erer ve standart saat dilimine 1 saat geri gider. Yani bazen ABD'deki zamanları karşılaştırırken fark 36001 saniye değil saniye civarındadır.

Ancak bu iki zaman değişikliği hakkında farklı bir şey var. İkincisi sürekli değişir ve birincisi sadece bir değişiklikti. Aynı miktarda geri dönmedi ya da tekrar değişmedi.

Ekrandaki gibi UTC olmayan bir zaman kullanmanız gerekmedikçe, zamanın değişmediği UTC'yi kullanmak daha iyidir.