Birisi lütfen mevcut "en iyi uygulama" Dateve Calendartürleri hakkında tavsiye verebilir .

Yeni kod yazarken, her zaman iyilik etmek en iyisidir Calendarüzerinde Dateveya orada şartlar nerede Datedaha uygun veri türü nedir?

Tarih daha basit bir sınıftır ve temel olarak geriye dönük uyumluluk nedeniyle vardır. Belirli tarihler ayarlamanız veya tarih aritmetiği yapmanız gerekiyorsa, bir Takvim kullanın. Takvimler ayrıca yerelleştirmeyi de ele alır. Tarihin önceki tarih düzenleme işlevleri kullanımdan kaldırılmıştır.

Şahsen ya milisaniye cinsinden zamanı uzun (ya da uygunsa Uzun) ya da bir seçenek olduğunda Takvim'i kullanma eğilimindeyim.

Hem Tarih hem de Takvim değiştirilebilir, bu da bir API'de kullanıldığında sorunlar sunma eğilimindedir.

Yeni kod için en iyi yol (politikanız üçüncü taraf koduna izin veriyorsa) Joda Time kitaplığını kullanmaktır .

Hem Tarih hem de Takvim'de , yeni kod için iyi çözümler olmayan pek çok tasarım sorunu var.

• Dateve Calendargerçekten aynı temel kavramdır (her ikisi de bir anı temsil eder ve altta yatan bir longdeğerin etrafını sarar ).

• Kişi , haftanın günü ve günün saati gibi şeyler hakkında somut gerçekler sunduğu gibi Calendar, aslında olduğundan daha kırılmışDate olduğunu iddia edebilirken , timeZonemülkünü değiştirirseniz , beton boşluklara dönüşür! Her iki nesne de bu nedenle yıl-ay-gün veya günün saati deposu olarak gerçekten kullanışlı değildir .

• CalendarSadece verildiğinde Dateve TimeZonenesnelerde sizin için hesaplamalar yapacak bir hesap makinesi olarak kullanın . Bir uygulamada özellik yazarken kullanımından kaçının.

• Görüntüleme Dizeleri oluşturmak SimpleDateFormatiçin TimeZoneve ile birlikte kullanın Date.

• Maceraperest hissediyorsanız, Joda-Time'ı kullanın, ancak gereksiz bir şekilde karmaşık IMHO olmasına rağmen ve yakında herhangi bir olayda JSR-310 tarih API'sının yerini alacaktır.

• Daha önce, tarih hesaplamaları için başlık altında YearMonthDaykullanan kendi sınıfınızı yuvarlamanın zor olmadığını cevapladım Calendar. Öneri için reddedildim, ancak hala geçerli olduğuna inanıyorum çünkü Joda-Time (ve JSR-310 ) çoğu kullanım durumu için gerçekten çok karmaşık.

Tarih, bir tarih nesnesini depolamak için en iyisidir. Bu ısrarcı, Serialize olan ...

Takvim Tarihleri ​​düzenlemek için en iyisidir.

Not: biz de bazen java.lang.Long Tarih üzerinde uzun, çünkü Tarih değiştirilebilir ve bu nedenle iş parçacığı güvenli değildir. Bir Date nesnesinde, ikisi arasında geçiş yapmak için setTime () ve getTime () kullanın. Örneğin, uygulamada sabit bir Tarih (örnekler: sıfır 1970/01/01 veya 2099/12/31 olarak ayarladığınız bir uygulama END_OF_TIME; bunlar, null değerleri başlangıç ​​ve bitiş zamanı olarak değiştirmek için çok yararlıdır, özellikle veritabanında kalmaya devam ettiğinizde, SQL null'lara özgüdür).

Mümkünse genellikle Date kullanıyorum. Değişken olmasına rağmen, mutasyoncular aslında kullanımdan kaldırılmıştır. Sonunda temel olarak tarih / saati temsil edecek uzun bir süre sarar. Tersine, değerleri değiştirmek zorunda kalsam Takvimler'i kullanırdım.

Bunu şu şekilde düşünebilirsiniz: StringBuffer'ı yalnızca kolayca yönetebileceğiniz ve ardından toString () yöntemini kullanarak Dizelere dönüştürmeniz gerektiğinde kullanın. Aynı şekilde Takvim'i yalnızca geçici verileri işlemem gerektiğinde kullanıyorum.

En iyi uygulama için, etki alanı modelinin dışında mümkün olduğunca değişmez nesneleri kullanma eğilimindeyim . Herhangi bir yan etki olasılığını önemli ölçüde azaltır ve sizin için bir JUnit testi yerine derleyici tarafından yapılır. Bu tekniği sınıfınızda özel final alanları oluşturarak kullanırsınız .

Ve StringBuffer benzetmesine geri dönüyorum. Takvim ve Tarih arasında nasıl dönüşüm yapacağınızı gösteren bazı kodlar

String s = "someString"; // immutable string
StringBuffer buf = new StringBuffer(s); // mutable "string" via StringBuffer
buf.append("x");
assertEquals("someStringx", buf.toString()); // convert to immutable String

// immutable date with hard coded format.  If you are hard
// coding the format, best practice is to hard code the locale
// of the format string, otherwise people in some parts of Europe
// are going to be mad at you.
Date date =     new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH).parse("2001-01-02");

// Convert Date to a Calendar
Calendar cal = Calendar.getInstance();
cal.setTime(date);

// mutate the value
cal.add(Calendar.YEAR, 1);

// convert back to Date
Date newDate = cal.getTime();

// 
assertEquals(new SimpleDateFormat("yyyy-MM-dd", Locale.ENGLISH).parse("2002-01-02"), newDate);

Dates zaman içinde değişmez noktalar olarak kullanılmalıdır; Calendars değiştirilebilir, ve bir son tarih bulmak için diğer sınıflarla işbirliği gerekiyorsa geçilebilir ve değiştirilebilir. Onlara benzer düşünün Stringve StringBuildernasıl kullanılmaları gerektiğini düşündüğümü anlayacaksınız.

(Ve evet, Date'in teknik olarak değişmez olmadığını biliyorum, ancak niyet, değişmez olmamalı ve hiçbir şey kullanımdan kaldırılan yöntemleri çağırmıyorsa, öyle.)

tl; Dr.

mevcut "en iyi uygulamayı" tavsiye eder DateveCalendar

en iyisi her zaman lehine olan CalendaraşırıDate

Bu eski sınıflardan tamamen kaçının . Kullanım java.time yerine sınıfları.

• Bir an için UTC kullanın (modern eşdeğer )Instant
Date
• Belirli bir saat dilimindeki bir an için (modern eşdeğerini ) kullanın.ZonedDateTime
GregorianCalendar
• UTC'den belirli bir uzaklıktaki bir an için şunu kullanın (eski sınıflarda eşdeğeri yok)OffsetDateTime
  
• Bilinmeyen saat dilimi veya ofseti olan bir tarih-saat (an değil) için şunu kullanın (eski sınıflarda eşdeğer değil)LocalDateTime
  

ayrıntılar

Ortomala tarafından cevap Lokni çağdaş kullanarak önermek doğru java.time oldukça zahmetli eski eski tarih-saat sınıfları (daha sınıflar Date, Calendarvb.) Ancak bu Cevap yanlış sınıfı eşdeğer olarak önermektedir (bu Cevap hakkındaki yorumuma bakın).

Java.time kullanma

Java.time sınıfları , eski tarih-saat sınıfları, gece ve gündüz farkı üzerinde büyük bir gelişmedir. Eski sınıflar kötü tasarlanmış, kafa karıştırıcı ve zahmetlidir. Mümkün olduğunca eski sınıflardan kaçınmalısınız. Ancak eski / yeniye / yenisinden dönüştürmeniz gerektiğinde, eski sınıflara eklenen yeni yöntemleri çağırarak bunu yapabilirsiniz .

Dönüştürme hakkında daha fazla bilgi için, başka bir Soruya cevap ve nifty şemasına bakın , java.util'i dönüştürün. .

Yığın Taşması aranması, java.time kullanımıyla ilgili yüzlerce örnek Soru ve Cevap verir. Ama işte kısa bir özet.

Instant

Mevcut anı bir ile alın Instant. InstantSınıfı zaman çizelgesinde bir anı temsil UTC çözünürlüğe sahip nanosaniye (ondalık kesir dokuz (9) haneye kadar).

Instant instant = Instant.now();

ZonedDateTime

Aynı anda , belirli bir bölgenin duvar saati süresinin merceğinden aynı anda görmek için , bir saat dilimi ( ZoneId) uygulayın ZonedDateTime.

Saat dilimi

Bir belirtme uygun bir zaman dilimi adı biçiminde continent/regiongibi America/Montreal, Africa/Casablancaya da Pacific/Auckland. Hiçbir zaman gibi 3-4 harfli bir kısaltma kullanın ESTveya ISToldukları gibi değil , gerçek zaman dilimleri, değil standardize ve hatta benzersiz değil (!).

ZoneId z = ZoneId.of( "America/Montreal" );
ZonedDateTime zdt = instant.atZone();

dengelemek

Saat dilimi, bir bölgenin UTC'den uzaklığındaki değişiklik geçmişidir . Ama bazen sadece tam bölge olmayan bir ofset verilir. Bu durumda OffsetDateTimesınıfı kullanın .

ZoneOffset offset = ZoneOffset.parse( "+05:30" );
OffsetDateTime odt = instant.atOffset( offset );

Bir zaman diliminin kullanılması, sadece bir ofsetin kullanılması tercih edilir.

LocalDateTime

Local…Sınıflardaki “Yerel” , belirli bir yer değil, herhangi bir yer anlamına gelir . Yani adı karşı sezgisel olabilir.

LocalDateTime, LocalDateve LocalTimeofset veya saat dilimi hakkında herhangi bir bilgi içermemesi. Onlar do Yani değil gerçek anları temsil, bunlar değil puan cetvelinde. Şüphe veya karmaşa, kullandığınızda ZonedDateTimeyerine LocalDateTime. Daha fazla tartışma için Yığın Taşması'nda arama yapın.

Teller

Tarih ve saat nesnelerini, değerlerini temsil eden dizelerle sınırlamayın. Bir tarih-saat nesnesi almak için bir dizeyi ayrıştırabilir ve bir tarih-saat nesnesinden bir dize oluşturabilirsiniz. Ama dize asla tarih-zamanın kendisi değildir.

Java.time sınıflarında varsayılan olarak kullanılan standart ISO 8601 biçimleri hakkında bilgi edinin .

Hakkında java.time

Java.time çerçevesi daha sonra Java 8 ve yerleşiktir. Bu sınıflar zahmetli eski yerini mirası gibi tarih-saat sınıfları java.util.Date, Calendar& SimpleDateFormat.

Artık bakım modunda olan Joda-Time projesi java.time sınıflarına geçişi tavsiye ediyor .

Daha fazla bilgi için Oracle Eğiticisine bakın . Ve birçok örnek ve açıklama için Stack Overflow'da arama yapın. Spesifikasyon JSR 310'dur .

JDBC 4.2 veya sonraki bir sürümüyle uyumlu bir JDBC sürücüsü kullanarak , java.time nesnelerini doğrudan veritabanınızla değiştirebilirsiniz. Dizelere veya java.sql. * Sınıflarına gerek yoktur.

Java.time sınıflarını nereden edinebilirsiniz?

• Java SE 8 , Java SE 9 ve üstü
  • Dahili.
  • Paketlenmiş bir uygulamaya sahip standart Java API'sinin bir parçasıdır.
  • Java 9 bazı küçük özellikler ve düzeltmeler ekler.
• Java SE 6 ve Java SE 7
  • Java.time işlevinin çoğu, ThreeTen-Backport'ta Java 6 ve 7'ye geri yüklenmiştir .
• Android
  • Android'in sonraki sürümleri java.time sınıflarının uygulamalarını bir araya getirir.
  • Önceki Android için, ThreeTenABP projesi ThreeTen-Backport'u uyarlar (yukarıda belirtilmiştir). Bkz . ThreeTenABP nasıl kullanılır… .

ThreeTen-Ekstra proje ek sınıfları ile java.time uzanır. Bu proje, java.time'a gelecekteki olası eklemeler için bir kanıt zeminidir. Burada bazı yararlı sınıfları gibi bulabilir Interval, YearWeek, YearQuarter, ve daha .

Java 8 ile yeni java.time paketi kullanılmalıdır.

Nesneler değiştirilemez, saat dilimleri ve gün ışığından yararlanma dikkate alınır.

Bunun gibi ZonedDateTimeeski bir nesneden nesne oluşturabilirsiniz java.util.Date:

    Date date = new Date();
    ZonedDateTime zonedDateTime = date.toInstant().atZone(ZoneId.systemDefault());

Her zaman Joda-time'ı savunuyorum . İşte nedeni.

1. API tutarlı ve sezgiseldir. Java.util.Date/Calendar API'larının aksine
2. java.text.SimpleDateFormat vb. aksine, iş parçacığı sorunlarından muzdarip değildir (Standart tarih / saat biçimlendirmesinin iş parçacığı için güvenli olmadığını fark etmemeyle ilgili birçok müşteri sorunu gördüm)
3. Java 8 için planlanan yeni Java tarih / saat API'larının ( JSR310) temelidir. Böylece çekirdek Java API'ları olacak API'ları kullanacaksınız.

DÜZENLEME: Java 8'e geçiş yapabiliyorsanız, Java 8 ile sunulan Java tarih / saat sınıfları artık tercih edilen çözümdür

Partide biraz geç, ancak Java'nın JDK 8'de yeni bir Date Time API'sı var. JDK sürümünüzü yükseltmek ve standardı benimsemek isteyebilirsiniz. Artık dağınık tarih / takvim yok, artık 3. parti kavanoz yok.

Tarih yeniden geliştirilmelidir. Uzun bir tamsayı olmak yerine, yılı, ayı, tarihi, saati, dakikayı, saniyeyi ayrı alanlar olarak tutmalıdır. Bu tarihin ilişkilendirildiği takvimi ve saat dilimini saklamak bile iyi olabilir.

Doğal sohbetimizde, 1 Kasım 2013 13:00 NY Saatinde bir randevu ayarladıysanız, bu bir DateTime. Bu bir takvim DEĞİLDİR. Bu yüzden Java'da da bu şekilde sohbet edebilmeliyiz.

Tarih uzun bir tamsayı olarak saklandığında (1 Ocak 1970'ten beri mili saniye cinsinden), geçerli tarihinin hesaplanması takvime bağlıdır. Farklı takvimler farklı tarihler verir. Bu, mutlak bir zaman verme olasılığından kaynaklanmaktadır (örneğin, Big Bang'den 1 trilyon saniye sonra). Ancak çoğu zaman, yıl, ay vb. İçeren bir nesne gibi uygun bir konuşma şekline de ihtiyacımız var.

Java'da bu 2 hedefi uzlaştırmak için yeni gelişmeler olup olmadığını merak ediyorum. Belki de java bilgim çok eski.

Btw "tarih" genellikle "eski / kullanımdan kaldırıldı" olarak etiketlenir (Tam olarak nedenini bilmiyorum) - orada bir şey yazılır Java: Neden Tarih yapıcı kullanımdan kaldırıldı ve bunun yerine ne kullanıyorum?

Yeni tarih (int yıl, int ay, int gün) aracılığıyla kurucu için bir sorun gibi görünüyor , önerilen yol Takvim ile ve parametreleri ayrı ayrı ayarlıyor .. ( Calendar cal = Calendar.getInstance (); )

Takvim'i, zaman içinde hareket etmek gibi tarihler üzerinde bazı özel işlemlere ihtiyaç duyduğumda kullanıyorum, ancak Tarih İhtiyaçlarınızı uyarlamak için tarihi biçimlendirmeniz gerektiğinde yararlı buluyorum, son zamanlarda Locale'in çok sayıda yararlı işlem ve yöntem olduğunu keşfettim. Şu anda Locale kullanıyorum!