अलग-अलग समय क्षेत्रों पर मिलीसेकंड की संख्या के साथ तिथि क्यों बदल रही है?

Question

हम जानते हैं कि java.util.Date की getTime विधि 1 जनवरी, 1 9 70 से 00:00:00 GMT इस दिनांक ऑब्जेक्ट द्वारा दर्शाए गए मिलीसेकंड की संख्या लौटाती है।

मैंने नीचे एक अजीब स्थिति देखी है;

सिस्टम समय क्षेत्र है: (UTC + 02: 00) इस्तांबुल

Date currentDate = new Date(); 
System.out.println(currentDate .getTime()); 
System.out.println(currentDate); 

जावा ConsoleOutput:

बुध 13 फ़र, 13:00:17 वीईटी 2013

---

तब मेरी जावास्क्रिप्ट प्लगइन इस लंबी वस्तु का उपयोग नीचे की तरह है;

जावास्क्रिप्ट:

console.log(new Date(1360753217219)); 

ब्राउज़र ConsoleOutput:

दिनांक {बुध फ़र, 13 2013 13:00:17 GMT + 0200 (तुर्की मानक समय)}

---

हालांकि ठीक है, ठीक है! परिवर्तन के बाद मेरा स्थानीय समय क्षेत्र(यूटीसी -04: 30) कराकास, स्थिति और घंटा नीचे मिलीसेकंड की संख्या के साथ नीचे बदल रहा है;

---

जावास्क्रिप्ट:

console.log(new Date(1360753217219)); 

ब्राउज़र ConsoleOutput:

दिनांक {बुध फ़र, 13 2013 06:30:17 GMT-0430 (वेनेजुएला मानक समय)}

क्या कोई इसे समझा सकता है? क्या वह जेएस बग है? या सबसे महत्वपूर्ण बात यह है कि, मैं जावा पक्ष पर इसे कैसे संभालना चाहिए, जेएस पक्ष पर विभिन्न समय क्षेत्रों के लिए समान संख्या में मिलीसेकंड के साथ उसी तारीख को प्राप्त करने के लिए?

धन्यवाद!

Answer 1

कोई बग नहीं, यह सिर्फ समय क्षेत्र कैसे काम करता है।

अगर आप किसी को वेनेज़ुएला में अभी कॉल करते हैं और उससे पूछें कि वह कितना समय है, तो वह आपको बताएगा कि यह 6.5 (आपके उदाहरण के अनुसार) टर्की में समय से पहले घंटे था।

जैसा आपने बताया है, जिस नंबर से आप काम कर रहे हैं, वह 1 9 70 से मिलीसेकंड की संख्या का प्रतिनिधित्व करता है, 00:00:00 जीएमटी, उसी समय कैरकास में, 31.12 था।1 9 6 9 1 9:30 जीएमटी-0430

इसलिए, हालांकि कई सेकंड बाद, वेनेज़ुएला में समय जीएमटी की तुलना में 4:30 घंटे पहले भी होगा।

यदि आप एक ही इनपुट (मिलीसेकंड) का उपयोग करते हैं तो आप अलग-अलग समय क्षेत्रों में सटीक उसी तारीख को नहीं प्राप्त कर सकते हैं क्योंकि यह गलत होगा।

यदि आप एक ही परिणाम प्राप्त करना चाहते हैं, तो आप आउटपुट में टाइमज़ोन (इस मामले में 6.5 घंटे) में अंतर जोड़ सकते हैं। डॉ। ड्रेडेल की सलाह के बाद, आपको शायद मिलीसेकंड से गड़बड़ नहीं करनी चाहिए।

Answer 2

मिलीसेकंड समय क्षेत्र अज्ञेयवादी हैं। समय 1 जनवरी 1 9 70 जीएमटी के बाद से पूर्ण के रूप में मापा जाता है। तो, विचार यह है कि आप मिलीसेकंड प्राप्त करते हैं और फिर कार्य करते हैं कि किसी दिए गए समय क्षेत्र के लिए स्थानीय समय तथ्य के बाद क्या होता है। यदि आप इसके बारे में सोचते हैं, तो यह समझ में आता है। 1 9 70 से पारित मिलीसेकंड की संख्या वही है चाहे आप कहीं भी हों।

यह थोड़ा उलझन में पड़ता है लेकिन समय क्षेत्र के लिए समायोजित करने के लिए मिलीसेकंड के साथ नूडल न करें। प्रत्येक तिथि पुस्तकालय में एक समय क्षेत्र विशिष्ट स्थानीय समय में मिलीसेकंद टिकट का अनुवाद करने के लिए तंत्र होते हैं।

तो अगर अपने विशिष्ट सवाल यह है कि (क्या करें कि आपके द्वारा उपयोग किए जा रहे महत्वपूर्ण नहीं है) सर्वर और ग्राहक के बीच प्रभावी ढंग से संवाद करने के लिए तिथि है, इस सवाल का जवाब यह मिलीसेकेंड आगे पीछे गुजरती हैं और पर बाहर काम करने के लिए पूरी तरह से सुरक्षित है है या तो आप जिस वैश्विक विशिष्ट समय के बारे में बात कर रहे हैं, उसके पक्ष में, यदि उस समय के साथ आप क्या कर रहे हैं इसके संदर्भ में यह महत्वपूर्ण है।

Answer 3

tl; डॉ

Instant.ofEpochMilli(1_360_753_217_219L)   // UTC 

2013-02-13T11: 00: 17.219Z

Instant.ofEpochMilli(1_360_753_217_219L)  
     .atZone(ZoneId.of("Europe/Istanbul")) // Same moment, two hours *ahead* of UTC. 

2013-02-13T13: 00: 17.219 + 02: 00 [यूरोप/इस्तांबुल]

Instant.ofEpochMilli(1_360_753_217_219L)  
     .atZone(ZoneId.of("America/Caracas")) // Same moment, four-and-a-half hours *behind* UTC. 

2013-02-13T06: 30: 17.219-04: 30 [अमेरिका/कराकस]

java.time

आप परेशानी पुराने तिथि-समय जल्द से जल्द बंडल के साथ वर्गों का उपयोग कर रहे हैं का उपयोग करना जावा के संस्करण। वे अब विरासत हैं, जावा.टाइम कक्षाओं द्वारा प्रदान की जाती हैं, किसी भी मंच पर सर्वोत्तम दिनांक-समय पुस्तकालय।

UTC (1 980-01-01T00: 00: 00Z) में 1 9 70 की शुरुआत में epoch reference date के बाद से मिलीसेकंड की संख्या से शुरू करें। अन्य बताते हैं कि आप यह नहीं समझ सकते कि एक युग संदर्भ दिनांक में समय क्षेत्र है, और यहां इस युग के साथ कि क्षेत्र यूटीसी है, जो शून्य घंटों का ऑफसेट है। अन्य सभी ऑफ़सेट इस के खिलाफ मापा जाता है, यूटीसी से आगे या यूटीसी के पीछे कई घंटे और मिनट।

Instant वर्ग ((9) एक दशमलव भिन्न के अंकों को नौ तक) nanoseconds के एक संकल्प के साथ UTC में समय रेखा पर एक पल के प्रतिनिधित्व करता है।

long input = 1_360_753_217_219L ; 
Instant instant = Instant.ofEpochMilli(input) ; 

instant.toString(): 2013-02-13T11: 00: 17.219Z

आप किसी विशेष क्षेत्र के wall-clock time के लेंस के माध्यम से है कि एक ही पल को देखने के लिए चाहते हैं, एक लागू समय क्षेत्र।

एक समय क्षेत्र किसी विशेष क्षेत्र द्वारा उपयोग में ऑफसेट में अतीत, वर्तमान और भविष्य के परिवर्तनों का इतिहास है।

ऐसे America/Montreal, Africa/Casablanca, या Pacific/Auckland रूप continent/region के प्रारूप में एक proper time zone name निर्दिष्ट करें,। 0-या IST जैसे 3-4 अक्षर संक्षेप का उपयोग न करें क्योंकि सही समय क्षेत्र, मानकीकृत नहीं, और यहां तक ​​कि अनूठा (!) भी नहीं है।

ZoneId zEurope_Istanbul = ZoneId.of("Europe/Istanbul") ; 
ZonedDateTime zdtEurope_Istanbul = instant.atZone(zEurope_Istanbul) ; 

zdtEurope_Istanbul.toString(): 2013-02-13T13: 00: 17.219 + 02: 00 [यूरोप/इस्तांबुल]

आप किसी अन्य समय क्षेत्र आवेदन कर सकते हैं।

ZoneId zAmerica_Caracas = ZoneId.of("America/Caracas") ; 
ZonedDateTime zdtAmerica_Caracas = zdtEurope_Istanbul.withZoneSameInstant(zAmerica_Caracas) ; 

zdtAmerica_Caracas.toString(): 2013-02-13T06: 30: 17.219-04: 30 [अमेरिका/कराकस]

इस code live at IdeOne.com देखें।

इन तीन वस्तुओं, त्वरित & zdtEurope_Istanbul & zdtAmerica_Caracas, सब बहुत ही एक साथ पल, समय रेखा पर एक ही बिंदु का प्रतिनिधित्व ।

आपकी गिनती से युग यूटीसी में 11 बजे का प्रतिनिधित्व करता है। इस्तांबुल दो घंटे यूटीसी के आगे है, इसलिए उसी समय एक ही समय में 11 बजे के बाद दो घंटे, 1 अपराह्न (13:00) होता है। वेनेज़ुएला यूटीसी के पीछे है, इसलिए उसी समय एक ही समय में 6:30 बजे है। ये सब समझ में आता है, सभी एक ही पल लेकिन अलग दीवार घड़ी का समय।

आईएसओ 8601

का आदान प्रदान या तिथि-समय मूल्यों के भंडारण के लिए एक गिनती-से-युग का प्रयोग न करें। यह त्रुटि-प्रवण है, जो मानव द्वारा अर्थपूर्ण रूप से पढ़ने के लिए असंभव है, और संदिग्ध है क्योंकि कम से कम दो दर्जन युग संदर्भ विभिन्न सॉफ़्टवेयर सिस्टमों और विभिन्न ग्रैन्युलरिटीज़ (पूरे सेकेंड, मिलीसेकंड, माइक्रोसेकंड, नैनोसेकंड इत्यादि) द्वारा उपयोग में आने वाली तारीखें हैं।)।

अपने जेवीएम के बाहर दिनांक-समय मानों को पार करते समय, मानक प्रतिनिधित्व के लिए मानक ISO 8601 स्वरूपों का उपयोग करें। Java.time कक्षा स्ट्रिंग को पार्सिंग/जनरेट करते समय मानक स्वरूपों का डिफ़ॉल्ट रूप से उपयोग करती है। आप इस उत्तर के उदाहरण कोड में उन प्रारूपों को देख सकते हैं।

---

java.time

बारे java.time ढांचे जावा 8 और बाद में बनाया गया है।ये कक्षाएं परेशान पुराने legacyjava.util.Date, Calendar, & SimpleDateFormat जैसी समय-समय पर कक्षाएं प्रदान करती हैं।

Joda-Time प्रोजेक्ट, अब maintenance mode में, java.time कक्षाओं में माइग्रेशन की सलाह देता है।

और जानने के लिए, Oracle Tutorial देखें। और कई उदाहरणों और स्पष्टीकरणों के लिए स्टैक ओवरफ़्लो खोजें। विशिष्टता JSR 310 है।

जावा.टाइम कक्षाएं कहां प्राप्त करें?

• Java SE 8, Java SE 9, और बाद में
  • में निर्मित।
  • एक बंडल कार्यान्वयन के साथ मानक जावा एपीआई का हिस्सा।
  • जावा 9 कुछ मामूली विशेषताओं और सुधारों को जोड़ता है।
• Java SE 6 और Java SE 7
  • java.time कार्यक्षमता की ज्यादातर ThreeTen-Backport में जावा 6 & से 7 वापस भेजा गया है।
• Android
  • ThreeTenABP परियोजना adapts ThreeTen-backport विशेष रूप से (जैसा कि ऊपर उल्लेख) Android के लिए।
  • How to use ThreeTenABP… देखें।

ThreeTen-Extra परियोजना अतिरिक्त कक्षाओं के साथ java.time फैली हुई है। यह परियोजना java.time के संभावित भविष्य के जोड़ों के लिए एक सिद्ध भूमि है। आपको यहां कुछ उपयोगी कक्षाएं मिल सकती हैं जैसे Interval, YearWeek, YearQuarter, और more।