इन दो बार (1927 में) क्यों एक अजीब परिणाम दे रहा है?

Question

अगर मैं निम्नलिखित कार्यक्रम चलाता हूं, जो दो बार तार को 1 सेकंड के अलावा संदर्भित करता है और उनकी तुलना करता है:

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);
}

आउटपुट है:

353

क्यों ld4-ld3नहीं है 1(जैसा कि मैं समय में एक-दूसरे के अंतर से उम्मीद करूंगा), लेकिन 353?

अगर मैं बाद में तारीखों को 1 सेकंड में बदल दूं:

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

तब ld4-ld3होगा 1।

---

जावा संस्करण:

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

Comments

यह एक स्थानीय समस्या हो सकती है।

— थॉर्बजोरन रेव एंडरसन

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

— फिल एच।

जबरदस्त हंसी। उन्होंने इसे 2011 में jdk6 के लिए तय किया। फिर, उसके दो साल बाद, उन्हें पता चला कि इसे jdk7 में भी तय कर लेना चाहिए, .... 7u25 के रूप में तय किया गया था, ज़ाहिर है, मुझे रिलीज़ नोट में कोई संकेत नहीं मिला। कभी-कभी मुझे आश्चर्य होता है कि कितने बग ओरेकल को ठीक करते हैं और पीआर कारणों से इसके बारे में कोई नहीं बताता है।

— user1050755

इस तरह की चीजों के बारे में एक शानदार वीडियो: youtube.com/watch?v=-5wpm-gesOY

— Thorbjørn Ravn Andersen

@PhilH अच्छी बात यह है, वहाँ अभी भी छलांग सेकंड होगा। तो भी वह काम नहीं करता है।

— 12431234123412341234123

Answer 1

यह शंघाई में 31 दिसंबर को एक समय क्षेत्र परिवर्तन है।

देखें यह पेज शंघाई में 1927 के जानकारी के लिए। मूल रूप से 1927 के अंत में आधी रात को, घड़ियां 5 मिनट और 52 सेकंड में वापस चली गईं। तो "1927-12-31 23:54:08" वास्तव में दो बार हुआ, और ऐसा लग रहा है कि जावा इसे स्थानीय तारीख / समय के लिए बाद में संभव के रूप में पार्स कर रहा है - इसलिए अंतर।

समय क्षेत्र के अक्सर अजीब और अद्भुत दुनिया में बस एक और प्रकरण।

संपादित करें: प्रेस बंद करो! इतिहास में बदलाव ...

मूल प्रश्न नहीं रह गया है, काफी समान व्यवहार प्रदर्शित होता अगर के संस्करण 2013A के साथ पुनर्निर्माण TZDB । 2013a में, परिणाम 358 सेकंड होगा, जिसमें 23:54:08 के बजाय 23:54:03 का संक्रमण समय होगा।

मैंने केवल इस पर ध्यान दिया क्योंकि मैं इस तरह के सवालों को इकाई परीक्षणों के रूप में Noda Time में एकत्रित कर रहा हूं ... परीक्षण को अब बदल दिया गया है, लेकिन यह सिर्फ दिखाने के लिए जाता है - ऐतिहासिक डेटा भी सुरक्षित नहीं है।

संपादित करें: इतिहास फिर से बदल गया है ...

TZDB 2014f में, परिवर्तन का समय 1900-12-31 हो गया है, और अब यह मात्र 343 सेकंड का परिवर्तन है (इसलिए बीच का समय tऔर t+1344 सेकंड है, यदि आप देखें कि मेरा क्या मतलब है)।

संपादित करें: 1900 पर एक संक्रमण के आसपास एक प्रश्न का उत्तर देने के लिए ... यह जावा टाइमज़ोन कार्यान्वयन की तरह दिखता है जो 1900 UTC के शुरू होने से पहले किसी भी पल के लिए उनके मानक समय में होने के रूप में सभी समय क्षेत्रों का इलाज करता है :

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);
            }
        }
    }
}

ऊपर दिया गया कोड मेरे विंडोज मशीन पर कोई आउटपुट नहीं देता है। तो किसी भी समय क्षेत्र में 1900 की शुरुआत में इसके मानक एक के अलावा कोई भी ऑफसेट है जो संक्रमण के रूप में गिना जाएगा। TZDB के पास स्वयं कुछ डेटा पहले की तुलना में वापस जा रहा है, और "निश्चित" मानक समय के किसी भी विचार पर भरोसा नहीं करता है (जो कि getRawOffsetएक वैध अवधारणा है) इसलिए अन्य पुस्तकालयों को इस कृत्रिम संक्रमण की आवश्यकता नहीं है।

Comments

@ जॉन: जिज्ञासा से बाहर, उन्होंने इस तरह के "अजीब" अंतराल द्वारा अपनी घड़ियों को वापस क्यों सेट किया? एक घंटे की तरह कुछ भी तर्कसंगत लगता होगा, लेकिन यह कैसे आया 5: 52mins?

— जोहान्स रुडोल्फ

@ जोहान्स: इसे विश्व स्तर पर सामान्य समय क्षेत्र बनाने के लिए, मेरा मानना ​​है - परिणामी ऑफसेट UTC + 8 है। पेरिस ने 1911 में इसी तरह का काम किया था। उदाहरण के लिए: timeanddate.com/worldclock/clockchange.html?n=195&year=1911

— जॉन स्कीट

@ क्या आपको पता है कि सितंबर 1752 में Java / .NET का मुकाबला होता है? मैं हमेशा यूनिक्स सिस्टम पर लोगों को 9 9 1752 दिखाते हुए प्यार करता था

— श्री मूस

तो पहले स्थान पर हेक शंघाई से 5 मिनट बाहर क्यों था?

— Igby Largeman

@ घर: बहुत सारे स्थानों पर कम पारंपरिक ऑफसेट थे। कुछ देशों में, अलग-अलग कस्बों में प्रत्येक की अपनी-अपनी ऑफसेट भौगोलिक दृष्टि से संभव के रूप में सही होने के करीब थी।

— जॉन स्कीट

Answer 2

आप एक स्थानीय समय की कमी का सामना कर चुके हैं :

जब स्थानीय मानक समय रविवार तक पहुंचने वाला था, 1. जनवरी 1928, 00:00:00 घड़ियां शनिवार, 31 दिसंबर को 0:05:52 बजे पीछे की ओर मुड़ गईं। दिसंबर 1927, 23:54:08 स्थानीय मानक समय

यह विशेष रूप से अजीब नहीं है और एक समय या दूसरे समय में हर जगह बहुत ज्यादा हुआ है क्योंकि समय-समय पर राजनीतिक या प्रशासनिक कार्यों के कारण टाइमज़ोन को बदल दिया गया या बदल दिया गया।

Answer 3

इस विचित्रता का नैतिक है:

• जहां तक ​​संभव हो UTC में दिनांक और समय का उपयोग करें।
• यदि आप UTC में कोई दिनांक या समय प्रदर्शित नहीं कर सकते, तो हमेशा समय-क्षेत्र का संकेत दें।
• यदि आपको यूटीसी में इनपुट तिथि / समय की आवश्यकता नहीं हो सकती है, तो स्पष्ट रूप से संकेतित समय-क्षेत्र की आवश्यकता होती है।

Comments

यूटीसी में रूपांतरण / भंडारण वास्तव में वर्णित समस्या के लिए मदद नहीं करेगा क्योंकि आप यूटीसी में रूपांतरण में असंतोष का सामना करेंगे।

— बेफिक्रे

@ मर्क मान: यदि आपका प्रोग्राम यूटीसी में आंतरिक रूप से सभी जगह यूटीसी का उपयोग करता है, तो केवल यूआई में स्थानीय समय-क्षेत्र से / में परिवर्तित होने पर, आप इस तरह की असंगतताओं की परवाह नहीं करेंगे ।

— Raedwald

@ रेवडवेल: निश्चित रूप से आप - 1927-12-31 23:54:08 के लिए UTC समय क्या होगा? (फिलहाल, नजरअंदाज करना, कि 1927 में भी UTC मौजूद नहीं था)। पर कुछ बिंदु इस समय और तारीख के लिए अपने सिस्टम में आ रहे हैं, और आप इसके साथ क्या करना है तय करने के लिए किया है। यूटीसी में इनपुट समय के लिए उपयोगकर्ता को बताना बस समस्या को उपयोगकर्ता के पास ले जाता है, यह इसे समाप्त नहीं करता है।

— निक बास्टिन

मैं इस थ्रेड पर गतिविधि की मात्रा पर विचार कर रहा हूं, जो कि लगभग एक साल से एक बड़े ऐप की तारीख / समय को फिर से भरने पर काम कर रहा है। यदि आप कैलेंडरिंग जैसी कोई चीज़ कर रहे हैं, तो आप UTC को "बस" स्टोर नहीं कर सकते हैं, क्योंकि समय क्षेत्र की परिभाषाएँ जिसमें इसे प्रस्तुत किया जा सकता है, समय के साथ बदल जाएगा। हम "उपयोगकर्ता इरादे का समय" - उपयोगकर्ता के स्थानीय समय और उनके समय क्षेत्र - और खोज और छँटाई के लिए यूटीसी को संग्रहीत करते हैं, और जब भी आईएएनए डेटाबेस को अपडेट किया जाता है, हम सभी यूटीसी समय को पुनर्गणना करते हैं।

— तैगानौत ta

Answer 4

जब वेतन वृद्धि का समय आपको वापस यूटीसी में परिवर्तित करना चाहिए और फिर जोड़ना या घटाना होगा। केवल प्रदर्शन के लिए स्थानीय समय का उपयोग करें।

इस तरह आप किसी भी अवधि से गुजर सकेंगे जहां घंटे या मिनट दो बार होते हैं।

यदि आप UTC में परिवर्तित हो गए हैं, तो प्रत्येक सेकंड जोड़ें, और प्रदर्शन के लिए स्थानीय समय में परिवर्तित करें। आप 23:54:08 के माध्यम से जाना होगा LMT - 11:59:59 बजे लाख मीट्रिक टन और उसके बाद 11:54:08 सीएसटी - 11:59:59 बजे सीएसटी।

Answer 5

प्रत्येक दिनांक को परिवर्तित करने के बजाय, आप निम्नलिखित कोड का उपयोग कर सकते हैं:

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

और फिर देखें कि परिणाम क्या है:

1

Comments

मुझे डर है कि ऐसा न हो। आप मेरे कोड को सिस्टम में आज़मा सकते हैं, यह आउटपुट करेगा 1, क्योंकि हमारे पास अलग-अलग स्थान हैं।

— Freewind

यह केवल सच है क्योंकि आपने पार्सर इनपुट में स्थान निर्दिष्ट नहीं किया है। यह खराब कोडिंग शैली और जावा में एक विशाल डिजाइन दोष है - इसका अंतर्निहित स्थानीयकरण। व्यक्तिगत रूप से, मैंने "TZ = UTC LC_ALL = C" हर जगह डाल दिया, जिससे बचने के लिए मैं जावा का उपयोग करता हूं। इसके अलावा, आपको कार्यान्वयन के हर स्थानीय संस्करण से बचना चाहिए जब तक कि आप किसी उपयोगकर्ता के साथ सीधे बातचीत नहीं कर रहे हैं और स्पष्ट रूप से चाहते हैं। स्थानीयकरणों सहित किसी भी गणना के लिए न करें, हमेशा लोकेले.आरओटी और यूटीसी टाइमज़ोन का उपयोग करें जब तक कि बिल्कुल आवश्यक न हो।

— user1050755

Answer 6

मुझे कहने के लिए खेद है, लेकिन समय की कमी थोड़ी सी बढ़ गई है

JDK 6 दो साल पहले, और JDK 7 में अभी हाल ही में अपडेट 25 में ।

सीखने के लिए सबक: प्रदर्शन के लिए छोड़कर, हर कीमत पर गैर-यूटीसी समय से बचें।

Comments

यह गलत है। डिसकंटिनिटी एक बग नहीं है - यह सिर्फ इतना है कि TZDB के अधिक हाल के संस्करण में थोड़ा अलग डेटा है। उदाहरण के लिए, जावा 8 के साथ मेरी मशीन पर, यदि आप "1927-12-31 23:54:02" और "1927-12-31 23:54:03" का उपयोग करने के लिए कोड को थोड़ा बदल देते हैं, तब भी आप एक देखेंगे डिसकंटिनिटी - लेकिन 353 सेकंड के बजाय अब 358 सेकंड। टीबीडीबी के और भी हाल के संस्करणों में अभी तक एक और अंतर है - विवरण के लिए मेरा जवाब देखें। यहाँ कोई वास्तविक बग नहीं है, बस एक डिज़ाइन निर्णय है कि अस्पष्ट तिथि / समय पाठ मूल्यों को कैसे पार्स किया जाता है।

— जॉन स्कीट

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

— प्लगवेट

Answer 7

जैसा कि अन्य लोगों द्वारा समझाया गया है, वहाँ एक समय की कमी है। वहाँ के लिए दो संभावित समय क्षेत्र ऑफसेट हैं 1927-12-31 23:54:08पर Asia/Shanghai, लेकिन केवल एक के लिए ऑफसेट 1927-12-31 23:54:07। इसलिए, जिस पर ऑफसेट का उपयोग किया जाता है, उसके आधार पर या तो एक सेकंड का अंतर या 5 मिनट और 53 सेकंड का अंतर होता है।

आम तौर पर एक घंटे की डेलाइट सेविंग (गर्मियों के समय) के बजाय ऑफसेट्स की यह थोड़ी सी शिफ्ट, समस्या को थोड़ा प्रभावित करती है।

ध्यान दें कि टाइमज़ोन डेटाबेस के 2013a अपडेट ने कुछ सेकंड पहले इस छूट को स्थानांतरित कर दिया था, लेकिन प्रभाव अभी भी देखने योग्य होगा।

java.timeजावा 8 पर नया पैकेज इसे अधिक स्पष्ट रूप से देखने देता है, और इसे संभालने के लिए उपकरण प्रदान करता है। दिया हुआ:

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());

फिर durationAtEarlierOffsetएक सेकंड durationAtLaterOffsetहोगा , जबकि पांच मिनट और 53 सेकंड का होगा।

इसके अलावा, ये दो ऑफ़सेट समान हैं:

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

लेकिन ये दोनों अलग हैं:

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

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

आप देख सकते हैं एक ही समस्या की तुलना 1927-12-31 23:59:59के साथ 1928-01-01 00:00:00, हालांकि, इस मामले में, यह पहले ऑफसेट कि लंबे समय तक विचलन पैदा करता है, और यह पहले की तारीख दो संभावित ऑफसेट किया है।

यह दृष्टिकोण करने का एक और तरीका यह जांचना है कि क्या कोई संक्रमण चल रहा है। हम इसे इस तरह कर सकते हैं:

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

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

आप जाँच सकते हैं कि क्या संक्रमण एक ओवरलैप है जहाँ उस दिनांक / समय के लिए एक से अधिक मान्य ऑफ़सेट हैं या उस ज़ोन आईडी के लिए - जहाँ दिनांक और समय मान्य नहीं है - isOverlap()और isGap()विधियों का उपयोग करके zot4।

मुझे उम्मीद है कि जावा 8 के व्यापक रूप से उपलब्ध होने या जावा 7 का उपयोग करने वालों के लिए जेएसआर 310 बैकपोर्ट को अपनाने के बाद लोग इस तरह के मुद्दे को सुलझाने में मदद करेंगे।

Comments

हाय डैनियल, मैंने आपका कोड ऑफ कोड चलाया है, लेकिन यह उम्मीद के मुताबिक आउटपुट नहीं दे रहा है। जैसे periodAtEarlierOffset और periodAtLaterOffset दोनों ही 1 सेकंड के हैं और zot3 और zot4 दोनों ही शून्य हैं। मैंने इस कोड को अपनी मशीन पर कॉपी किया है और चलाया है। क्या ऐसा कुछ है जो यहाँ किया जाना चाहिए। मुझे पता है कि क्या आप कोड का एक टुकड़ा देखना चाहते हैं। यहाँ कोड tutorialspoint.com/ है। क्या आप मुझे बता सकते हैं कि यहाँ क्या हो रहा है।

— विनेशचौहान

@vineeshchauhan यह जावा के संस्करण पर निर्भर करता है, क्योंकि यह tzdata में बदल गया है, और JDK के विभिन्न संस्करण tzdata के विभिन्न संस्करणों को बंडल करते हैं। मेरे द्वारा स्थापित जावा पर, बार हैं 1900-12-31 23:54:16और 1900-12-31 23:54:17, लेकिन यह आपके द्वारा साझा की गई साइट पर काम नहीं करता है, इसलिए वे I. से अलग जावा संस्करण का उपयोग कर रहे हैं

— डैनियल सी। सोबरल

Answer 8

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

• निर्यात LC_ALL = C TZ = UTC
• UTC को अपना सिस्टम क्लॉक सेट करें
• जब तक बिल्कुल आवश्यक न हो (केवल प्रदर्शन के लिए) स्थानीयकृत कार्यान्वयन का उपयोग न करें

करने के लिए जावा समुदाय प्रक्रिया सदस्यों मेरा सुझाव है:

• स्थानीय तरीकों को डिफ़ॉल्ट न बनाएं, लेकिन उपयोगकर्ता को स्थानीयकरण का स्पष्ट रूप से अनुरोध करने की आवश्यकता होती है।
• इसके बजाय FIXED डिफ़ॉल्ट के रूप में UTF-8 / UTC का उपयोग करें, क्योंकि यह केवल आज डिफ़ॉल्ट है। कुछ और करने का कोई कारण नहीं है, सिवाय इसके कि आप इस तरह से धागे का उत्पादन करना चाहते हैं।

मेरा मतलब है, चलो, वैश्विक स्थैतिक चर एक विरोधी ऊ पैटर्न नहीं हैं? और कुछ नहीं है, जो कुछ अल्पविकसित पर्यावरण चर द्वारा दिया गया विकृत स्वभाव है ......।

Answer 9

जैसा कि अन्य लोगों ने कहा, यह 1927 में शंघाई में एक समय परिवर्तन है।

जब यह 23:54:07शंघाई में था , स्थानीय मानक समय, लेकिन 5 मिनट और 52 सेकंड के बाद, यह अगले दिन में 00:00:00बदल गया, और फिर स्थानीय मानक समय वापस बदल गया 23:54:08। इसलिए, यही कारण है कि दो बार के बीच का अंतर 1 सेकंड नहीं 343 सेकंड है, जैसा कि आपने उम्मीद की होगी।

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

लेकिन इन दो समय परिवर्तनों के बारे में कुछ अलग है। उत्तरार्द्ध लगातार बदलता रहता है और पूर्व सिर्फ एक परिवर्तन था। यह वापस नहीं बदला या उसी राशि से फिर से बदल गया।

यूटीसी का उपयोग करना बेहतर है जहां समय तब तक नहीं बदलता है जब तक कि प्रदर्शन में गैर-यूटीसी समय का उपयोग करने की आवश्यकता न हो।