क्या "समय के अंत" के लिए एक निरंतर है?

Question

कुछ प्रणालियों के लिए, समय मूल्य 9999-12-31 का उपयोग "समय के अंत" के रूप में किया जाता है, जिस समय तक कंप्यूटर गणना कर सकता है। लेकिन अगर यह बदल जाए तो क्या होगा? क्या इस समय को बिलियन वैरिएबल के रूप में परिभाषित करना बेहतर नहीं होगा?

C और अन्य प्रोग्रामिंग भाषाओं में आमतौर पर एक वैरिएबल होता है जैसे MAX_INTकि सबसे बड़ा मूल्य एक पूर्णांक हो सकता है। एक समान कार्य क्यों नहीं किया जाता है MAX_TIMEअर्थात चर को "समय के अंत" पर सेट करें जो कि कई प्रणालियों के लिए आमतौर पर 9999-12-31 है। एक गलत वर्ष (9999) को हार्डकोडिंग की समस्या से बचने के लिए ये सिस्टम "समय के अंत" के लिए एक चर पेश कर सकते हैं?

** वास्तविक उदाहरण **

End of validity date: 31/12/9999.(आधिकारिक दस्तावेज इस तरह सूचीबद्ध हैं) ब्लॉगर एक पृष्ठ लिखना चाहता है जो हमेशा शीर्ष पर हो, स्वागत पृष्ठ। तो यह भविष्य में संभव के रूप में एक तारीख दी गई है:

3000? हां, आपका स्वागत है जो पृष्ठ 1 जनवरी 3000 पर पोस्ट किया गया है। इसलिए इस पृष्ठ को हमेशा के लिए ब्लॉग के शीर्ष पर रखा जाएगा =) यह वास्तव में 31 अगस्त 2007 को पोस्ट किया गया है।

Comments

क्यों? यह समस्या की तरह लगता है जिसे सही एल्गोरिदम या डेटा संरचना को लागू करके हल किया जा सकता है।

— व्यंग्यात्मक

मुझे लगता है कि ज्यादातर लोग अभी तक Y10K समस्या के बारे में ज्यादा चिंतित नहीं हैं :-) विशेष रूप से इससे पहले कि हम एक Y2038 समस्या के लिए बाध्य हैं , और शायद एक जोड़ी अधिक ...

— Péter Török

@ थोरबजर्न, हाँ, शायद अधिकांश लाइव सिस्टम तब तक माइग्रेट हो चुके होंगे। फिर भी, अभी भी पुराने एम्बेडेड सिस्टम, विरासत डेटाबेस, अप्रचलित फ़ाइल स्वरूपों में फ़ाइलों आदि की एक वर्तमान में अयोग्य राशि हो सकती है

— Péter Török

मुझे लगता है कि मय कैलेंडर के पास "समय समाप्त होने वाला" स्थिर = 2012-12-21 ;-)

— नीकी

कोई नहीं जानता कि "समय का अंत" कब होगा।

— ट्यूलेंस कोरडोवा

Answer 1

अपने आप से पूछें कि आपको पहली बार इस तरह के एक चर की आवश्यकता क्यों है।

सबसे अधिक संभावना है, आप अपने डेटा के बारे में झूठ बोल रहे हैं: जब भी आपको "समय के अंत" चर की आवश्यकता होती है, तो आप समय के वास्तविक अंत की बात नहीं कर रहे होते हैं; बल्कि आप ऐसी चीजों को व्यक्त कर रहे हैं जैसे "इस तिथि के लिए कोई ऊपरी बाध्यता नहीं है", "यह घटना अनिश्चित काल तक जारी रहती है", या इसी तरह की।

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

बेशक, सही समाधान हमेशा संभव नहीं होता है, इसलिए हो सकता है कि आप सभी के बाद एक जादुई मूल्य का उपयोग कर रहे हों, लेकिन जब आप ऐसा करते हैं, तो आपको प्रति मामले के आधार पर एक उचित मूल्य तय करना होगा, क्योंकि जो तारीखें करते हैं और नहीं करते हैं यह सुनिश्चित करें कि आप जिस डोमेन पर मॉडलिंग कर रहे हैं, उस पर निर्भर करता है - यदि आप लॉग टाइमस्टैम्प का भंडारण कर रहे हैं, तो 01/01/2999 एक उचित "समय का अंत" है; आपके आवेदन की संभावनाएं अभी भी लगभग 1000 साल से इस्तेमाल की जा रही हैं, मुझे लगता है, व्यावहारिक रूप से शून्य होगा। इसी तरह के विचार कैलेंडर अनुप्रयोगों के लिए जाते हैं। लेकिन क्या होगा यदि आपका सॉफ़्टवेयर वैज्ञानिक डेटा को संभालना है, कहो, पृथ्वी की जलवायु के बारे में दीर्घकालिक भविष्यवाणियां? वे वास्तव में भविष्य में एक हजार साल देखना चाह सकते हैं। या इसे एक कदम आगे ले जाएं; खगोल विज्ञान, एक ऐसा क्षेत्र जहां अरबों वर्षों के आदेश पर बहुत बड़े समयों में इसका कारण पूरी तरह से सामान्य है, पथ और भविष्य दोनों में। उन लोगों के लिए, 01/01/2999 एक पूरी तरह से हास्यास्पद मनमाना है। ओटीओएच, एक कैलेंडर प्रणाली जो भविष्य में दस ट्रिलियन वर्ष तक के समय को संभालने में सक्षम है, शायद ही किसी दंत चिकित्सक नियुक्ति ट्रैकिंग प्रणाली के लिए व्यावहारिक है, यदि केवल भंडारण क्षमता के कारण।

दूसरे शब्दों में, एक मूल्य के लिए कोई सबसे अच्छा विकल्प नहीं है जो गलत है और मनमाने ढंग से शुरू करने के लिए मनमाना है। यही कारण है कि किसी भी प्रोग्रामिंग भाषा में परिभाषित एक को देखना वास्तव में असामान्य है; जो लोग आमतौर पर इसे "समय का अंत" नाम नहीं देते हैं, बल्कि कुछ ऐसा DATE_MAX(या Date.MAX) करते हैं, और इसका मतलब "सबसे बड़ा मूल्य है जिसे डेट डेटाइप में संग्रहीत किया जा सकता है", "समय का अंत" या नहीं "अनिश्चित काल"।

Comments

नल का उपयोग करने का मतलब है कि विशेष मूल्य का उपयोग करने की तुलना में वास्तव में कोई भी बेहतर नहीं है

— रायथल

@ रायथल खैर, मुझे लगता है कि कोई 'नुलनियम' बग नहीं है, इसलिए यह कम से कम थोड़ा बेहतर है ...

— केटेफ़

@ रायथल: वास्तव में यह नहीं है। बहुत सारे कार्य हैं जो आप एक जादुई संख्या पर कर सकते हैं जो आप अशक्त नहीं कर सकते।

— पीटर बी

@ रायथल - nullइस मामले में एक विशेष मूल्य के रूप में उपयोग नहीं किया जा रहा है, इसका सही अर्थ के रूप में उपयोग किया जा रहा है null, जो "गायब" है। तो अगर आपका क्षेत्र है ExpiryDate, जो अधिक सही है: null(जिसका अर्थ है कोई समाप्ति की तारीख) या END_OF_TIME(जो मौजूद नहीं है, जहां तक ​​हम जानते हैं)। स्पष्ट रूप nullसे NoValueया कुछ इसी तरह का बेहतर उपाय है।

— स्कॉट व्हिटलॉक

@jwenting - वे कोई भेद नहीं करते क्योंकि वहाँ कोई नहीं है। NULL का अर्थ है कि इसका अस्तित्व नहीं है या अधिक मानवीय शब्दों में मूल्य को केवल परिभाषित नहीं किया गया है।

— रामहाउंड

Answer 2

एक उद्योग के रूप में हम कुछ बाइट्स को बचाने की खोज में कुख्यात रहे हैं और मनमाने तरीके से हैं

• ३१ दिसम्बर ९९
• 19 जनवरी 2038
• T + 50 साल, जब उम्मीद है कि सभी सिस्टम जो मैं शामिल हो गए हैं वे विचलित हो गए हैं या बदल दिए गए हैं (या मैं मर चुका हूं, जो भी पहले आता है)।

IMHO सबसे अच्छा दांव 'अधिकतम तिथि' पर अमूर्तता की एक उपयुक्त, मुख्यधारा के स्तर के साथ रहना है, और उम्मीद है कि समय से पहले एक आम समाधान ने मुद्दे को संबोधित किया है।

जैसे .NET में, DateTime.MaxValue मनमाने ढंग से 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000। इसलिए यदि मेरी अपनी दीर्घायु के बारे में मेरी धारणाएं झूठी हैं, और वर्ष 10000 आता है, तो मैं उम्मीद कर रहा हूं कि फ्रेमवर्क के बाद के संस्करण के साथ मेरे ऐप की एक पुनरावृत्ति का विस्तार होगा DateTime.MaxValue(जैसे इसके अंतर्निहित प्रकार को बदलकर) एक नए मनमाने मूल्य पर और इस समस्या को एक और कुछ सहस्राब्दी के लिए सड़क के नीचे दबा दें।

संपादित करें

(Tdammers के पुन: लागू करने का मतलब है कि एक कृत्रिम तिथि को ठगने के बजाय, यह स्पष्ट रूप से उपभोक्ता को इस तथ्य को उजागर करने के लिए अधिक सही है कि हमारे पास अंतिम तिथि नहीं है।)

उपयोग करने के लिए एक विकल्प के रूप में null, जिसका किसी भी संदर्भ प्रकार (सहित .Net Nullable`) के साथ संगत होने का नकारात्मक परिणाम होता है, जो संभवतः उन उपभोक्ताओं में एनआरई मुद्दों का कारण होगा जो एफपी भाषाओं में जांच करना भूल जाते हैं, उनका उपयोग करना आम बात है एक मान के आसपास विकल्प या हो सकता है कि टाइप रैपर जो वापस आ सकता है, या नहीं।

छद्म कोड:

Option<DateTime> LeaseExpiryDate(Home rental) 
{
    if (... expiry date can be determined ...)
       return Some(rental.ExpiryDate);
    else
       return None;
}

ऐसा करने का लाभ यह है कि यह उपभोक्ता को दोनों मामलों में तर्क करने के लिए मजबूर करता है। पैटर्न मिलान भी यहाँ आम है:

LeaseExpiryDate(myHome) match {
     case Some(expiryDate) => "Expired"
     case None => "No Expiry"
}

Comments

ओह। मुझे अंधा। कोई बात नहीं।

— ott--

किसी दिन, शायद। हम तारीखों और समय के लिए एक विलियम कहान होगा । हमारे पास सकारात्मक और नकारात्मक रूप से अनंत टाइमस्टैम्प, " NaT" मूल्य, आदि

— रॉस पैटरसन

मदद नहीं की जा सकती है लेकिन इसे याद दिलाया जा सकता है: exit109.com/~ghealton/y2k/y2k_humor/Cobol.html

— Julia Hayward

Answer 3

आप शायद algebraic data typeअनंत बड़े के लिए एक संस्करण के साथ चाहते हैं date। फिर तुलना को परिभाषित करें, जिसमें infiniteसंस्करण हमेशा किसी भी अन्य की तुलना में बड़ा होगा date।

स्काला में उदाहरण:

sealed abstract class SmartTime extends Ordered[SmartTime] { x =>
        def compare(y: SmartTime) = {
                x match {
                        case InfiniteFuture => 1
                        case InfinitePast => -1
                        case ConcreteTime(x) =>
                                y match {
                                        case InfiniteFuture => -1
                                        case InfinitePast => 1
                                        case ConcreteTime(y) => x compare y
                                }
                }
        }
}
case class ConcreteTime(t: Long) extends SmartTime
case object InfiniteFuture extends SmartTime
case object InfinitePast extends SmartTime

http://ideone.com/K5Kuk

Comments

उत्तर के लिए अपने उत्तर में कोड को कोट करें।

— घातक

Answer 4

अपने समय को 64 बिट्स IEE754 डबल सटीक फ़्लोटिंग पॉइंट नंबर के रूप में संग्रहीत करें, और आप उपयोग कर सकते हैं +INF। एकल-परिशुद्धता का उपयोग न करें, यह केवल 7 अंकों के लिए सटीक है जो एक तारीख के लिए थोड़ा कम है।

Answer 5

कोको / ऑब्जेक्टिव-सी में फैक्ट्री के तरीके [NSDate distantPast] और [NSDate distantFuture] होते हैं, जो ठीक उसी तरह का प्रतिनिधित्व करते हैं जिस तरह की चीज का आप उल्लेख कर रहे हैं।

वर्तमान कार्यान्वयन द्वारा लौटाए गए मानों में निरंतर 0 AD और 4000 AD के निरूपण हैं, हालांकि ये गारंटी या दस्तावेज नहीं हैं।

Answer 6

आम तौर पर ऐसा कोई मूल्य नहीं होता है, क्योंकि यह भाषा के निर्माण के रूप में उपयोगी नहीं होगा।

MAX_INTऔर यह एक उद्देश्य है। ओवरफ्लो के खिलाफ जांच के लिए उन्हें आपके कोड में उपयोग किया जा सकता है। यह उपयोगी है अगर आप एरेज़, वैक्टर, जो भी हो, में बड़े डेटा ऑब्जेक्ट बनाने और प्रबंधित करने जा रहे हैं। यह एक काफी प्लेटफ़ॉर्म-विशिष्ट मूल्य भी है।

MAX_DATEमान के लिए उपयोग का मामला देखने में अधिक कठिन है। आमतौर पर ये सिर्फ मूल्य होते हैं, इन्हें प्रोग्राम की संरचना के हिस्से के रूप में उपयोग नहीं किया जाता है, और इसलिए चारों ओर घूमने वाले मूल्य प्रोग्राम के अनर्थकारी परिणाम नहीं होंगे (हालांकि यह डेटा के लिए हो सकता है)। साथ ही, C, C ++ आदि में दिनांक और समय के प्रकार आमतौर पर अधिक सख्ती से परिभाषित होते हैं; और इसलिए कार्यक्रम लिखने वाले लोगों को चिंता करने की ज़रूरत नहीं है कि यह प्लेटफार्मों के बीच बदल सकता है।

Answer 7

हमारे द्वारा किए गए एक प्रोजेक्ट पर, हमारे पास एक ऐसी स्थिति थी जहां कुछ डेटाबेस का साइज़िंग इस तरह से किया गया था कि सॉफ्टवेयर का उपयोग करने के 30 साल बाद टिकाऊ नहीं होगा। जब क्लाइंट ने उस समय हमारे लीड इंजीनियर से पूछा: "ठीक है, हम आपके सॉफ़्टवेयर का उपयोग करने के 30 साल बाद क्या करने जा रहे हैं?" हमारे लीड इंजीनियर, एक ककड़ी के रूप में शांत, एक श्रग के साथ जवाब दिया: "हम जाकर बीयर लेंगे!"

मुद्दा यह है, बस उस तारीख का उपयोग करें जो भविष्य में पर्याप्त है। संभावना है कि आपके सॉफ्टवेयर को उन्नत किया जाएगा या तब तक बदल दिया जाएगा। :)