Java 8 java.time sınıfları neden getMillis () yöntemini kullanmıyor?

Java 8, java.time paketindeki tarihler ve saatler için tamamen yeni bir kütüphaneye sahiptir; bu, JodaTime'ı daha önce kullanmak zorunda kalan veya kendi tarih işleme yardımcı yöntemlerini kullanmakta güçlük çeken herkese çok açık bir şeydir. Bu paketteki birçok sınıf, zaman damgalarını temsil eder ve zaman damgasından getHour()saat almak, zaman damgasından getMinute()dakika getNano()almak, zaman damgasından nanos almak vb. Gibi yardımcı yöntemlere sahiptir .

getMillis()Zaman damgasının millisini elde etmek için bir metot bulunmadığını fark ettim . Bunun yerine, birinin yöntemini çağırması gerekir get(ChronoField.MILLI_OF_SECOND). Bana göre kütüphanede bir tutarsızlık gibi görünüyor. Böyle bir yöntemin neden eksik olduğunu bilen veya Java 8'in hala geliştirilme aşamasında olduğunu bilen var mı, daha sonra eklenmesi olasılığı var mı?

https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html

Burada tanımlanan sınıflar, instantlar, süreler, tarihler, saatler, zaman dilimleri ve dönemler dahil olmak üzere ana tarih-zaman kavramlarını temsil eder. Proleptik Gregoryen kurallarını izleyen fiili dünya takvimi olan ISO takvim sistemine dayanır. Tüm sınıflar değişmez ve iplikte güvenlidir.

Her tarih saat örneği, API'ler tarafından rahatlıkla kullanılabilen alanlardan oluşur. Alanlara daha düşük seviyeli erişim için java.time.temporalpakete bakın . Her sınıf, tarih ve saatlerin her türünü yazdırma ve ayrıştırma desteği içerir. java.time.formatÖzelleştirme seçenekleri için pakete bakın ...

Bu tür bir sınıf örneği:
https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html

ISO-8601 takvim sisteminde 2007-12-03T10: 15: 30 gibi zaman dilimi olmayan bir tarih.

LocalDateTimegenellikle yıl-ay-gün-saat-dakika-saniye olarak görülen bir tarih-saati temsil eden değişmez bir tarih-saat nesnesidir. Yılın günü, haftanın günü ve yılın haftası gibi diğer tarih ve saat alanlarına da erişilebilir. Zaman nanosaniye hassasiyetine göre gösterilir. Örneğin, "2 Ekim 2007, 13: 45.30.123456789" değeri bir LocalDateTime...

JSR-310 , milisaniye yerine nanosaniye dayalıdır. Bu nedenle, en az sayıda mantıklı yöntem kümesi saat, dakika, saniye ve nanosaniye'ye dayanmaktadır. Bir nanosaniye üssü olma kararı, projenin orijinal kararlarından biriydi ve kesinlikle doğru olduğuna inandığım karardı.

Millis için bir yöntem eklemek, nanosaniye ile örtüşürdü, bariz olmayan bir yoldur. Kullanıcılar, nano alanın örneğin nano saniyeli mi yoksa milli nano-mi olduğunu düşünmek zorunda kalacaklardı. Kafa karıştırıcı ek bir yöntem eklemek arzu edilmez, bu yüzden yöntem ihmal edildi. Belirtildiği gibi, alternatif get(MILLI_OF_SECOND)mevcuttur.

FWIW, getMillis()yöntemi gelecekte eklemeye karşı çıkacağım .

OpenJDK'nın bir parçası olmadan önce, threeten github'taydı ve ondan önce sourceforge'deydi. O zamanlar, jsr-310'da bir şartname lideri olan Stephen Colebourne, sourceforge sitesinde bulabileceğiniz bir anket yaptı .

The fourth question on the survey covered the method names for LocalTime:
1) getHourOfDay(), getMinuteOfHour(), getSecondOfMinute(), getNanoOfSecond()
2) getHour(), getMinute(), getSecond(), getNanoOfSecond()
3) getHour(), getMinute(), getSecond(), getNano()
4) another idea

sadece% 6,23'ü cevap 4'ü seçti ve aralarında yaklaşık% 15'i a getMillis(), yani toplam oyların% 1'inden azını istedi .

Muhtemelen bu yüzden getMillisilk sırada yer almadı ve openjdk posta listesiyle ilgili hiçbir şey bulamadım, bu yüzden mesele daha sonra tartışılmayacaktı.

Belirsiz UTC zamanlarını temsil eden sınıflar (bunlar Instant, OffsetDateTime, ZonedDateTime), Java döneminden mutlak ofsete erişmek için, yani java.util.Date'de 'milisaniye zamanı' olarak adlandırdığınız, yani java.util.Date dediğiniz şey için iki yardımcı yönteme sahiptir. milisaniyede almak

long getEpochSecond()
int getNano()

1000L*getEpochSecond() + getNano() / 1000000L;

Bunun yerine neden seçildiğinin bazı nedenleri , bazıları kolaylık sağlamak için çıkardığım jsr 310 posta listesindelong getEpochMillis() tartışıldı :

milisaniye hassasiyetinin yeterli olmayacağını varsaymak makul görünüyor. Ancak, nanosaniye hassasiyetinden daha büyük bir şey aşırı görünüyor

...

Bunu uygulamak için tercih ettiğim seçenek 64 bit uzun saniye (imzalı) + 32 bit int nanosaniye (imzasız) olacaktır.

...

Bölünmenin, bilimdeki resmi SI zaman birimi ve evrensel olarak kabul görmüş en standart olan ikinci seviyede olmasını tercih ediyorum.

Gün düzeyinde bölünme, sıçrama saniye işlemlerini gerçekleştirmediği için instantlar için sorunludur. Milisaniye düzeyinde bölmek, Java'nın geri kalanıyla biraz daha iyi bütünleşirken, oldukça garip görünüyor. Ayrıca, desteklenen aralıkta kaybeder.

Önerilen şekilde ikinciye bölmek, 290 milyar yıl boyunca bir dizi nanosaniye instantı verir. Hiç kimse bu hassasiyeti bu zaman dilimi aralığında kullanmamalı olsa da, onu desteklemekten daha kolay bir şekilde desteklemesini öneririm.

Geliştiricilerin çeşitli seçenekler arasındaki farkları anlamaya çalışacaklarını ve sadece yeni sınıfları (yanlış) kullanmayacaklarını umarak, java.util.Date'den JSR310 sınıflarına kasıtlı olarak dönüştürmeyi zorlaştırmak için başka bir neden olduğunu hissediyorum.

LocalDateTimeSınıfın neden bu metotlara sahip olmadığına dair - muhtemelen orada LocalDateTimebulunamamaktadır, çünkü hangi bölgede bulunduğunuzu veya UTC ofsetinizin ne olduğuna karar verene kadar UTC zaman çizelgesine bağlı değildir, kendiniz hangi noktada OffsetDateTimeveya ZonedDateTime(her ikisi de gerekli yöntemlere sahip).

Alternatif olarak, milisaniye cinsinden bir tür süre elde etmek için kendinize ait bir LOCAL_EPOCHsabit tanımlayabilir 1970-01-01T00:00:00ve daha sonra bir şeyi yapabilirsiniz MILLIS.between(LOCAL_EPOCH, localTime). Bununla birlikte, bu değer, yerel saatinizi UTC saati olarak tanımlamazsanız System.currentTimeMilliseconds()ya da tarafından döndürülen herhangi bir değerle uyumlu olmayacaktır java.util.Date.getTime(); ancak bu durumda, InstantO'yu veya ZoneOffset.UTC ile OffsetDateTime özelliğini de kullanabilirsiniz.