आम सुविधाएं
a) दोनों पुस्तकालय अपरिवर्तनीय प्रकारों का उपयोग करते हैं। जोडा-टाइम अतिरिक्त म्यूटेबल प्रकार भी प्रदान करता है MutableDateTime।
बी) इसके अलावा: दोनों पुस्तकालय एरिक इवांस के डिजाइन अध्ययन "टाइमएंडमनी" से प्रेरित हैं या मार्टिन फावलर से डोमेन संचालित शैली के बारे में विचार करते हैं ताकि वे एक धाराप्रवाह प्रोग्रामिंग शैली के लिए कम या ज्यादा प्रयास करें (हालांकि हमेशा सही नहीं; ;-))।
ग) दोनों पुस्तकालयों के साथ हमें एक वास्तविक कैलेंडर तिथि प्रकार (कहा जाता है LocalDate), एक वास्तविक दीवार समय प्रकार (कहा जाता है LocalTime) और रचना (कहा जाता है LocalDateTime)। पुराने java.util.Calendarऔर की तुलना में यह बहुत बड़ी जीत है java.util.Date।
डी) दोनों पुस्तकालय एक विधि-केंद्रित दृष्टिकोण का उपयोग करते हैं जिसका अर्थ है कि वे उपयोगकर्ता को getDayOfYear()इसके बजाय उपयोग करने के लिए प्रोत्साहित करते हैं get(DAY_OF_YEAR)। इसकी तुलना में बहुत अधिक अतिरिक्त विधियां होती हैं java.util.Calendar(हालांकि बाद में टाइप के अत्यधिक उपयोग के कारण यह बिल्कुल सुरक्षित नहीं है)।
प्रदर्शन
अन्य जवाब देखें @ OO7 द्वारा मिखाइल वोर्त्सोव के विश्लेषण की ओर इशारा करते हुए हालांकि बिंदु 3 (अपवाद को पकड़ने) शायद अप्रचलित है - इस JDK- बग को देखें । विभिन्न प्रदर्शन (जो जेएसआर -310 के सामान्य पक्ष में है ) मुख्य रूप से इस तथ्य के कारण है कि जोडा-टाइम का आंतरिक कार्यान्वयन हमेशा मशीन-टाइम की तरह लंबे-आदिम (मिलीसेकंड में) का उपयोग करता है।
शून्य
Joda-Time अक्सर NULL का उपयोग सिस्टम टाइमज़ोन के लिए डिफ़ॉल्ट, डिफ़ॉल्ट लोकेल, वर्तमान टाइमस्टैम्प आदि के रूप में करता है जबकि JSR-310 लगभग हमेशा NULL मानों को अस्वीकार करता है।
शुद्धता
JSR-310 नैनो- सेकंड की सटीकता को संभालती है, जबकि Joda-Time को मिलीसेकंड परिशुद्धता तक सीमित किया जाता है ।
समर्थित फ़ील्ड:
Java-8 (JSR-310) में समर्थित फ़ील्ड के बारे में एक अवलोकन कुछ वर्गों द्वारा टेम्पोरल-पैकेज (उदाहरण के लिए ChronoField और WeekFields ) में दिया गया है, जबकि Joda-Time इस क्षेत्र में कमज़ोर है - DateTimeFieldType देखें । जोडा-टाइम की सबसे बड़ी कमी यहां स्थानीयकृत सप्ताह से संबंधित क्षेत्रों की अनुपस्थिति है। दोनों क्षेत्र कार्यान्वयन डिजाइन की एक सामान्य विशेषता यह है कि दोनों प्रकार के मानों पर आधारित हैं (कोई अन्य प्रकार नहीं, यहां तक कि एनम भी नहीं)।
enum
JSR-310 प्रस्तावों enums चाहते DayOfWeekया Monthजबकि Joda समय इसकी पेशकश नहीं करता है क्योंकि यह मुख्य रूप से पहले के वर्षों 2002-2004 में विकसित किया गया था जावा 5 ।
जोन एपीआई
a) JSR-310, Joda-Time की तुलना में अधिक टाइमज़ोन सुविधाएँ प्रदान करता है। लैटर टाइमजोन ऑफसेट संक्रमण के इतिहास के लिए एक प्रोग्रामेटिक पहुंच प्राप्त करने में सक्षम नहीं है, जबकि JSR-310 ऐसा करने में सक्षम है।
बी) आपकी जानकारी के लिए: JSR-310 ने अपनी आंतरिक टाइमज़ोन रिपॉजिटरी को एक नए स्थान और एक अलग प्रारूप में स्थानांतरित कर दिया है। पुराने लाइब्रेरी फ़ोल्डर lib / zi का कोई अस्तित्व नहीं है।
समायोजक बनाम संपत्ति
JSR-310 ने TemporalAdjusterअस्थायी गणना और जोड़तोड़ को औपचारिक रूप से लागू करने के लिए एक औपचारिक तरीके के रूप में -इंटरफेस पेश किया है , विशेष रूप से लाइब्रेरी या फ्रेमवर्क-लेखकों के लिए यह JSR-310 के नए एक्सटेंशन को स्थिर करने के लिए एक अच्छा और सापेक्ष आसान तरीका है (स्थैतिक सहायक के बराबर) पूर्व के लिए कक्षाएं java.util.Date)।
हालांकि अधिकांश उपयोगकर्ताओं के लिए, इस सुविधा का बहुत सीमित मूल्य है क्योंकि कोड लिखने का बोझ अभी भी उपयोगकर्ता के पास है। नई- TemporalAdjusterअवधारणा के आधार पर निर्मित समाधान इतने सारे नहीं हैं, वर्तमान में केवल TemporalAdjustersहेरफेर का एक सीमित सेट (और एनम Monthया अन्य अस्थायी प्रकार) के साथ सहायक वर्ग है ।
जोडा-टाइम एक फील्ड-पैकेज प्रदान करता है, लेकिन अभ्यास ने सबूत दिखाया है कि नए क्षेत्र कार्यान्वयन कोड के लिए बहुत कठिन हैं। दूसरी तरफ Joda-Time तथाकथित गुण प्रदान करता है जो JSR-310 की तुलना में कुछ जोड़तोड़ को बहुत आसान और अधिक सुरुचिपूर्ण बनाते हैं, उदाहरण के लिए property.withMaximumValue () ।
कैलेंडर सिस्टम
JSR-310 4 अतिरिक्त कैलेंडर सिस्टम प्रदान करता है। सबसे दिलचस्प एक उमलकुरा (सऊदी अरब में इस्तेमाल किया गया) है। अन्य 3 हैं: Minguo (ताइवान), जापानी (1871 के बाद से केवल आधुनिक कैलेंडर!) और थाईबुद्धवादी (केवल 1940 के बाद सही)।
Joda-Time एक इस्लामिक कैलेंडर प्रदान करता है जो गणना के आधार पर आधारित है - न कि उमालकुरा जैसा कोई दिखने वाला कैलेंडर। थाई-बौद्ध भी एक समान रूप में जोडा-टाइम द्वारा प्रस्तुत किया जाता है, मिगुओ और जापानी एक नहीं। अन्यथा जोडा-टाइम कोप्टिक और इथियोपिक कैलेंडर प्रदान करता है, वह भी (लेकिन अंतर्राष्ट्रीयकरण के समर्थन के बिना)।
यूरोपीय लोगों के लिए अधिक दिलचस्प: जोडा-टाइम ग्रेगोरियन , जूलियन और मिश्रित-ग्रेगोरियन-जूलियन कैलेंडर भी प्रदान करता है । हालांकि, वास्तविक ऐतिहासिक गणना के लिए व्यावहारिक मूल्य सीमित है क्योंकि विभिन्न वर्ष जैसे महत्वपूर्ण तारीख इतिहास में शुरू होते हैं, बिल्कुल भी समर्थन नहीं किया जाता है (वही आलोचना पुराने के लिए मान्य है java.util.GregorianCalendar)।
अन्य कैलेंडर जैसे हिब्रू या फ़ारसी या हिंदू दोनों पुस्तकालयों में पूरी तरह से गायब हैं।
युग दिन
JSR-310 वर्ग है JulianFields जबकि Joda समय (संस्करण 2.0) वर्ग में कुछ सहायक तरीके प्रदान करता है DateTimeUtils ।
घड़ियों
JSR-310 का कोई इंटरफ़ेस (एक डिज़ाइन गलती) नहीं है, लेकिन एक सार वर्ग java.time.Clockजो किसी भी घड़ी निर्भरता इंजेक्शन के लिए इस्तेमाल किया जा सकता है। Joda-Time इंटरफ़ेस MillisProvider और इसके बजाय DateTimeUtils में कुछ सहायक तरीके प्रदान करता है । तो इस तरह जोडा-टाइम विभिन्न घड़ियों (मॉकिंग आदि) के साथ परीक्षण-संचालित मॉडल का समर्थन करने में भी सक्षम है।
अवधि अंकगणित
दोनों पुस्तकालय एक या अधिक लौकिक इकाइयों में समय दूरी की गणना का समर्थन करते हैं। हालांकि, जब सिंगल-यूनिट-ड्यूरेशन को हैंडल करते हैं JSR-310-style स्पष्ट रूप से अच्छे हैं (और इंट का उपयोग करने के बजाय लंबे समय से आधारित):
JSR-310 => long days = ChronoUnit.DAYS.between(date1, date2);
जोडा-समय => int days = DAYS.daysBetween(date1, date2).getDays();
मल्टीपल यूनिट-ड्यूरेशन के हैंडलिंग भी अलग-अलग हैं। यहां तक कि गणना के परिणाम अलग-अलग हो सकते हैं - यह बंद Joda-Time समस्या देखें । जबकि JSR-310 एक बहुत ही सरल और सीमित दृष्टिकोण का उपयोग करता है बस वर्गों Period(वर्षों, महीनों और दिनों के आधार पर अवधि) और Duration(सेकंड और नैनोसेकंड के आधार पर) का उपयोग करने के लिए, जोडा-टाइम वर्ग का उपयोग करने के लिए और अधिक परिष्कृत तरीके का उपयोग करता PeriodTypeहै ताकि नियंत्रण हो सके किन इकाइयों में एक अवधि (Joda-Time इसे "Period" कहते हैं) व्यक्त की जाएगी। जबकिPeriodType-एपीआई किसी तरह से उपयोग करने के लिए अजीब है जेएसआर -310 द्वारा बिल्कुल भी पेश नहीं किया गया है। विशेष रूप से JSR-310 मिश्रित तिथि और समय अवधि (उदाहरण के लिए दिन और घंटे के आधार पर) को परिभाषित करना संभव नहीं है। अगर एक पुस्तकालय से दूसरे पुस्तकालय में प्रवास की बात आती है तो चेतावनी दी जाए। आंशिक रूप से समान श्रेणी के नामों के बावजूद चर्चा में पुस्तकालय असंगत हैं।
अंतराल
जेएसआर -310 इस सुविधा का समर्थन नहीं करता है जबकि जोडा-टाइम के पास सीमित समर्थन है। यह भी देखें इस SO-जवाब ।
स्वरूपण और पार्सिंग
दोनों पुस्तकालयों की तुलना करने का सबसे अच्छा तरीका समान-नाम वाली कक्षाओं DateTimeFormatterBuilder (JSR-310) और DateTimeFormatterBuilder (Joda-Time) को देखना है । JSR-310-वैरिएंट थोड़ा अधिक शक्तिशाली है (किसी भी प्रकार के हैंडल को भी TemporalFieldप्रदान कर सकता है बशर्ते कि फ़ील्ड इंप्लॉयर कुछ एक्सटेंशन पॉइंट्स जैसे रिज़ॉल्यूशन () ) को कोड करने में कामयाब हो । हालांकि सबसे महत्वपूर्ण अंतर है - मेरी राय में:
JSR-310 ज्यादा बेहतर समयसीमा के नाम (प्रारूप पैटर्न प्रतीक z) को बेहतर बना सकता है जबकि Joda-Time अपने पहले के संस्करणों में और अब केवल बहुत सीमित तरीके से ऐसा नहीं कर सकता।
JSR-310 का एक और फायदा स्टैंडअलोन महीने के नामों के लिए समर्थन है जो रूसी या पोलिश आदि भाषाओं में महत्वपूर्ण है। जोडा-टाइम के पास ऐसे संसाधनों तक पहुंच नहीं है - जावा -8 प्लेटफार्मों पर भी नहीं।
JSR-310 की तुलना में पैटर्न सिंटैक्स भी Joda-Time की तुलना में अधिक लचीला है, वैकल्पिक वर्गों (वर्ग कोष्ठक का उपयोग करके) के लिए अनुमति देता है, CLDR-standard की ओर अधिक उन्मुख है और पेडिंग (अक्षर प्रतीक p) और अधिक फ़ील्ड प्रदान करता है।
अन्यथा यह ध्यान दिया जाना चाहिए कि Joda-Time, PeriodFormatter का उपयोग करके अवधि का प्रारूपण कर सकता है । JSR-310 ऐसा नहीं कर सकता।
आशा है कि यह अवलोकन मदद करेगा। सभी एकत्रित जानकारी मुख्य रूप से मेरे प्रयासों और जांच के कारण है कि एक बेहतर तारीख और समय पुस्तकालय को कैसे डिजाइन और कार्यान्वित किया जाए (कुछ भी सही नहीं है)।
2015-06-24 से अपडेट करें:
इस बीच मैंने जावा में विभिन्न समय पुस्तकालयों के लिए एक सारणीबद्ध अवलोकन लिखने और प्रकाशित करने का समय ढूंढ लिया है । टेबल में Joda-time v2.8.1 और Java-8 (JSR-310) के बीच तुलना भी है। यह इस पोस्ट की तुलना में अधिक विस्तृत है।