सवाल इन दो बार (1 9 27 में) क्यों अजीब परिणाम दे रहा है?


यदि मैं निम्न प्रोग्राम चलाता हूं, जो दो दिनांक तारों को संदर्भित करता है तो 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

6025
2017-07-27 08:15


मूल


क्या आप वास्तव में वास्तविक जीवन परिदृश्य में उस सटीक स्थिति पर ठोकर खा चुके थे या क्या यह प्रश्न केवल एक गूढ़ व्यक्ति था - बस इसके मजाक के लिए? - Costi Ciudatu
@ कोस्टी सियुडैटू: एफडब्ल्यूआईडब्लू, मैं आसानी से कल्पना कर सकता हूं कि यह एक बड़ी बग को कम करने के परिणामस्वरूप आ रहा है - यानी, "इन दोनों तिथियों को साल भर अलग क्यों नहीं किया जाता है?" - Brooks Moses
असली जवाब हमेशा होता है, हमेशा लॉगिंग के लिए एक युग के बाद सेकंड का उपयोग करें, यूनिक्स युग की तरह, 64 बिट पूर्णांक प्रतिनिधित्व के साथ (हस्ताक्षर किए, यदि आप युग से पहले टिकटों को अनुमति देना चाहते हैं)। किसी वास्तविक दुनिया के समय प्रणाली में कुछ गैर-रैखिक, गैर-मोनोटोनिक व्यवहार होते हैं जैसे लीप घंटे या डेलाइट बचत। - Phil H
मूल रूप से पोस्ट किया गया ओरेकल बग आईडी 7070044 23 जुलाई 11 को - Arno
@ कोस्टी सिउदातु के रूप में, मुझे आश्चर्य है कि ओपी ने किस बग रिपोर्ट को खोला था। मुझे यह भी सुनिश्चित है कि एक पहेली होने के अलावा यह 99.9 (9 अंकों के बहुत सारे जोड़ें) उपयोगकर्ताओं के प्रतिशत के लिए उपयोगी नहीं है। वह प्रतिष्ठा "खेल" के लिए पदक प्राप्त करता है। - Menelaos Bakopoulos


जवाब:


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

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

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

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

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

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

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

टीजेडीडीबी 2014 एफ में, परिवर्तन का समय 1 9 00-12-31 तक चला गया है, और अब यह केवल 343 दूसरा परिवर्तन है (इसलिए समय t तथा t+1 344 सेकेंड है, यदि आप देखते हैं कि मेरा क्या मतलब है)।

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

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

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


9729
2017-07-27 08:31



@ गैरेथ: नहीं, लेकिन उस अवधि में शंघाई समय क्षेत्र संक्रमण के विवरण की जांच करना मेरा पहला बंदरगाह था। और मैं हाल ही में नोडा टाइम के लिए समय क्षेत्र संक्रमण पर काम कर रहा हूं, इसलिए अस्पष्टता की संभावना मेरे विचारों के सबसे आगे है ... - Jon Skeet
@ जोहान्स: इसे अधिक वैश्विक रूप से सामान्य समय क्षेत्र बनाने के लिए, मुझे विश्वास है - द जिसके परिणामस्वरूप ऑफसेट यूटीसी +8 है। उदाहरण के लिए पेरिस ने 1 9 11 में इसी तरह की चीज की थी: timeanddate.com/worldclock/clockchange.html?n=195&year=1911 - Jon Skeet
@ चार्ल्स: फिर वापस, यात्रियों को स्थानीय समय की हर जगह अलग होने की उम्मीद थी (क्योंकि यह था)। इसके अतिरिक्त, घड़ियों यांत्रिक थे और जल्दी से बहती थीं, इसलिए जब लोग यात्रा नहीं करते थे, तब भी हम उन्हें स्थानीय घड़ी के अनुसार स्थानीय घड़ी के अनुसार समायोजित करते थे। तो टावर घड़ियों (जो भी बहाव) सेट थे? सूर्य को अपने दैनिक शिखर तक पहुंचने पर उन्हें आसानी से 12:00 तक सेट करके ... जो कि प्रत्येक स्थान पर अलग-अलग ऊंचाई पर अलग नहीं था। जब तक रेलरोड समय सारिणी को कुछ प्रकार के मानकीकरण की आवश्यकता नहीं होती तब तक यह आदर्श कहीं भी आदर्श था। - Michael Borgwardt
लेकिन फिर: पृथ्वी पर इस प्रकार का ज्ञान उम्र से कैसे बच गया है, ताकि लगभग एक शताब्दी पहले, यह सॉफ्टवेयर में लागू किया गया हो? 2011 में, जो भी गैर-सॉफ्टवेयर अभियंता को टाइमज़ोन विषमता का उल्लेख करता है उसे एक बेवकूफ की तरह देखा जाता है। (और वास्तव में, लोग सभी सॉफ़्टवेयर को अमूर्त करने की अपेक्षा करते हैं, और यदि वे 'दोपहर' कहते हैं, तो वे अस्पष्ट नहीं होते हैं, हम सॉफ्टवेयर इंजीनियर को इससे निपटना चाहिए)। लेकिन दिसंबर 1 9 27 में शांगई में किसी की कल्पना करने के लिए, सोच रहा है कि यह ऐसी चीज को नोट करना प्रासंगिक होगा, और किसी भी तरह से यह जानकारी कभी खोई नहीं गई, हटाई गई, कुछ भी ... दिमाग उड़ा। - phtrivier
@EdS। यह वास्तव में केवल 15 मिनट का समय लेता है, जिस कारण से यह 16 मिनट का अंतर दिखाता है, वह 27 जुलाई 2011 को मामूली टाइमज़ोन विसंगति के कारण है, जिसके कारण जॉन स्कीट कितना शानदार है। - JessieArr


आप का सामना करना पड़ा है स्थानीय समय असंतोष:

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

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


1463
2017-07-27 08:38



@ जेसन: सोने के पढ़ने के लिए, मैं सुझाव देता हूं कि (अब) आईएएनए टाइमज़ोन डेटाबेस (पहले ओल्सन नामक एक प्यारे लड़के द्वारा प्रशासित, मुझे लगता है) एक महान संसाधन होगा: iana.org/time-zones। जहां तक ​​मुझे पता है, ओपन सोर्स वर्ल्ड (इस प्रकार पुस्तकालयों का उल्लेख किया गया) का अधिकांश हिस्सा इसे टाइमज़ोन डेटा के प्राथमिक स्रोत के रूप में उपयोग करता है। - Sune Rasmussen


इस अजीबता का नैतिक है:

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

580
2017-07-28 11:50



यूटीसी में रूपांतरण / भंडारण वास्तव में वर्णित समस्या के लिए मदद नहीं करेगा क्योंकि आप यूटीसी में रूपांतरण में असंतुलन का सामना करेंगे। - unpythonic
@ मार्क मैन: यदि आपका प्रोग्राम आंतरिक रूप से हर जगह यूटीसी का उपयोग करता है, तो केवल यूआई में स्थानीय समय-क्षेत्र में / से कनवर्ट करना, आप नहीं करेंगे देखभाल इस तरह के असंतोष के बारे में। - Raedwald
@ रेडवाल्ड: निश्चित रूप से आप करेंगे - 1 927-12-31 23:54:08 के लिए यूटीसी समय क्या है? (इस पल के लिए अनदेखा, कि यूटीसी 1 9 27 में भी अस्तित्व में नहीं था)। पर कुछ इस समय इंगित करें और तिथि आपके सिस्टम में आ रही है, और आपको यह तय करना होगा कि इसके साथ क्या किया जाए। उपयोगकर्ता को बताते हुए कि उन्हें यूटीसी में समय इनपुट करना है, समस्या को उपयोगकर्ता को ले जाता है, यह इसे खत्म नहीं करता है। - Nick Bastin
मैं इस धागे पर गतिविधि की मात्रा पर सही महसूस करता हूं, जो अब लगभग एक साल के लिए एक बड़े ऐप की तारीख / समय पर काम कर रहा है। यदि आप कैलेंडिंग की तरह कुछ कर रहे हैं, तो आप यूटीसी को "बस" स्टोर नहीं कर सकते हैं, क्योंकि समय क्षेत्र की परिभाषाओं को समय के साथ बदल दिया जाएगा। हम "उपयोगकर्ता इरादा समय" स्टोर करते हैं - उपयोगकर्ता का स्थानीय समय और उनका समय क्षेत्र - और खोज और सॉर्ट करने के लिए यूटीसी, और जब भी आईएएनए डेटाबेस अपडेट किया जाता है, हम सभी यूटीसी समयों का पुनर्मूल्यांकन करते हैं। - taiganaut


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

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

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


320
2017-07-30 16:55





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

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

और परिणाम देखें:

1

265
2018-05-16 05:31



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


मुझे यह कहने में खेद है कि, लेकिन समय असंतुलन थोड़ा सा हो गया है

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

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


188
2018-02-17 22:44



यह गलत है। विघटन एक बग नहीं है - यह सिर्फ इतना है कि TZDB का एक नवीनतम संस्करण थोड़ा अलग डेटा है। उदाहरण के लिए, जावा 8 के साथ मेरी मशीन पर, यदि आप "1927-12-31 23:54:02" और "1 927-12-31 23:54:03" का उपयोग करने के लिए कोड को बहुत थोड़ा बदलते हैं, तो आप अभी भी एक देखेंगे असंतोष - लेकिन अब 358 सेकेंड के बजाय, 353 के बजाय। टीजेडीबी के हाल के संस्करणों में अभी भी एक और अंतर है - विवरण के लिए मेरा उत्तर देखें। यहां कोई वास्तविक बग नहीं है, केवल एक डिज़ाइन निर्णय है कि अस्पष्ट दिनांक / समय टेक्स्ट मानों को कैसे पार्स किया जाता है। - Jon Skeet
वास्तविक समस्या यह है कि प्रोग्रामर यह नहीं समझते कि स्थानीय और सार्वभौमिक समय (किसी भी दिशा में) के बीच रूपांतरण 100% विश्वसनीय नहीं हो सकता है। पुराने टाइमस्टैम्प के लिए हमारे पास जो समय स्थानीय समय था, वह सबसे अच्छा था। भविष्य के टाइमस्टैम्प के लिए राजनीतिक कार्य किसी स्थानीय समय के लिए सार्वभौमिक समय को बदल सकते हैं। वर्तमान और हाल के पिछले टाइमस्टैम्प के लिए आपको समस्या हो सकती है कि tz डेटाबेस को अपडेट करने और परिवर्तनों को रोल करने की प्रक्रिया कानूनों के कार्यान्वयन अनुसूची की तुलना में धीमी हो सकती है। - plugwash


जैसा कि दूसरों द्वारा समझाया गया है, वहां एक समय विघटन होता है। के लिए दो संभावित टाइमज़ोन ऑफ़सेट हैं 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 व्यापक रूप से उपलब्ध होने के बाद या जेएसआर 310 बैकपोर्ट को अपनाने वाले जावा 7 का उपयोग करने वाले लोगों के लिए इस तरह के मुद्दे को संभालने में लोगों की मदद करता है।


168
2018-01-03 14:43



हाय डैनियल, मैंने कोड का अपना टुकड़ा चलाया है लेकिन यह उम्मीद के अनुसार आउटपुट नहीं दे रहा है। अवधि की तरहएटअयरलीऑफसेट और अवधि एटलाटर ऑफसेट दोनों केवल 1 सेकंड हैं और zot3 और zot4 दोनों शून्य हैं। मैंने बस अपनी मशीन पर कॉपी किया है और यह कोड चलाया है। क्या ऐसा कुछ भी है जो यहां किया जाना चाहिए। अगर आप कोड का एक टुकड़ा देखना चाहते हैं तो मुझे बताएं। कोड यहाँ है tutorialspoint.com/... क्या आप मुझे बता सकते हैं कि यहां क्या हो रहा है। - vineeshchauhan
@ वीनेशचौहान यह जावा के संस्करण पर निर्भर करता है, क्योंकि यह tzdata में बदल गया है, और जेडीके बंडल के विभिन्न संस्करण tzdata के विभिन्न संस्करणों में बदल गया है। अपने स्वयं के स्थापित जावा पर, समय हैं 1900-12-31 23:54:16 तथा 1900-12-31 23:54:17, लेकिन यह आपके द्वारा साझा की गई साइट पर काम नहीं करता है, इसलिए वे I से भिन्न जावा संस्करण का उपयोग कर रहे हैं। - Daniel C. Sobral


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

  • निर्यात एलसी_ALL = सी टीजेड = यूटीसी
  • यूटीसी को अपनी सिस्टम घड़ी सेट करें
  • स्थानीयकृत कार्यान्वयन का कभी भी उपयोग न करें जब तक कि बिल्कुल जरूरी न हो (यानी केवल प्रदर्शन के लिए)

को जावा सामुदायिक प्रक्रिया सदस्य मैं अनुशंसा करता हूं:

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

मेरा मतलब है, चलो, वैश्विक स्थैतिक चर विरोधी एंटी-ओओ पैटर्न नहीं हैं? कुछ प्राथमिक पर्यावरण चर द्वारा दिए गए उन व्यापक दोषों को और कुछ नहीं .......


137
2017-11-26 15:58