"সময়ের শেষ" জন্য একটি ধ্রুবক আছে?

Question

কিছু সিস্টেমের জন্য, সময় মূল্য 9999-12-31 কম্পিউটারকে গণনা করতে পারে এমন সময় হিসাবে "সময়ের সমাপ্তি" হিসাবে ব্যবহৃত হয়। তবে কী বদলে যাবে? এই বারটি বিল্টিন ভেরিয়েবল হিসাবে সংজ্ঞায়িত করা ভাল না?

সি এবং অন্যান্য প্রোগ্রামিং ল্যাঙ্গুয়েজে সাধারণত MAX_INTএকটি পূর্ণসংখ্যার সবচেয়ে বড় মান পাওয়ার জন্য একটি ভেরিয়েবল যেমন বা এর অনুরূপ থাকে। কেন এর জন্য একটি অনুরূপ ফাংশন নেই MAX_TIMEঅর্থাত্ "সময়ের শেষে" পরিবর্তনশীল সেট করুন যা অনেক সিস্টেমে সাধারণত 9999-12-31 হয়। কোনও ভুল বছর (9999) তে হার্ডকোডিংয়ের সমস্যা এড়াতে এই সিস্টেমগুলি "সময়ের সমাপ্তি" এর জন্য কোনও পরিবর্তনশীল প্রবর্তন করতে পারে?

** আসল উদাহরণ **

End of validity date: 31/12/9999.(অফিসিয়াল ডকুমেন্টগুলি এইভাবে তালিকাভুক্ত করা হয়েছে) ব্লগার একটি পৃষ্ঠা লিখতে চান যা সর্বদা শীর্ষে থাকে, স্বাগত পৃষ্ঠা। সুতরাং এটি ভবিষ্যতে যতদূর সম্ভব একটি তারিখ দেওয়া হয়েছে:

3000? হ্যাঁ, আপনি যে স্বাগত পৃষ্ঠার মুখোমুখি হচ্ছেন তা 1 জানুয়ারী 3000 এ পোস্ট করা হয়েছে So সুতরাং এই পৃষ্ঠাটি চিরতরে ব্লগের শীর্ষে রাখা হবে =) এটি 31 আগস্ট 2007 এ পোস্ট করা হয়েছে।

Comments

কেন? এটি সমস্যার মতো মনে হচ্ছে যা সঠিক অ্যালগরিদম বা ডেটা কাঠামো প্রয়োগ করে সমাধান করা যেতে পারে।

— ইওফোরিক

আমি অনুমান করি যে বেশিরভাগ লোকেরা এখনও ওয়াই 10 কে সমস্যা নিয়ে খুব বেশি চিন্তিত নন :-) বিশেষত এর আগে যেমন আমাদের একটি Y2038 সমস্যা হতে বাধ্য , এবং সম্ভবত আরও দু'একটা ...

— পিটার তারেক

@ থরবজর্ন, হ্যাঁ, সম্ভবত বেশিরভাগ লাইভ সিস্টেমগুলি তখনই স্থানান্তরিত হয়ে গেছে। যাইহোক, এখনও অপ্রচলিত ফাইল ফরম্যাট ইত্যাদি পুরাতন এমবেডেড সিস্টেম, লিগ্যাসি ডেটাবেস ফাইল বর্তমানে অমূল্য পরিমাণ হতে পারে

— পিটার Török

আমি মনে করি মায়ান ক্যালেন্ডারের একটি "সময়ের শেষ" ধ্রুবক = 2012-12-21 ;-)

— নিকি

"সময়ের শেষ" কখন হবে তা কেউ জানে না।

— তুলাইনস কর্ডোভা

Answer 1

নিজেকে জিজ্ঞাসা করুন কেন আপনাকে প্রথমে এ জাতীয় পরিবর্তনশীল দরকার।

সম্ভবত, আপনি আপনার ডেটা সম্পর্কে মিথ্যা বলছেন: যখনই আপনার "সময়ের সমাপ্তি" ভেরিয়েবলের প্রয়োজন হয়, আপনি সময়ের আসল শেষের কথা উল্লেখ করছেন না; বরং আপনি "এই তারিখের জন্য কোনও উচ্চতর আবদ্ধ নেই", "এই ইভেন্টটি অনির্দিষ্টকালের জন্য অব্যাহত থাকবে", বা অনুরূপ মত প্রকাশ করছেন।

তারপরে সঠিক সমাধানটি হ'ল যাদু মানের উপর নির্ভর করার পরিবর্তে এই অভিপ্রায়গুলি সরাসরি প্রকাশ করা: নুলযোগ্য তারিখের প্রকারগুলি (যেখানে null"শেষের তারিখ সেট নেই" নির্দেশ করে) ব্যবহার করুন, একটি "অনির্দিষ্ট" বুলিয়ান ক্ষেত্র যুক্ত করুন, একটি পলিমারফিক রিভার ব্যবহার করুন (যা পারে হয় আসল তারিখ বা একটি বিশেষ "অনির্দিষ্ট" মান), বা আপনার প্রোগ্রামিং ভাষাতে যা কিছু দেওয়া হোক না কেন।

অবশ্যই, সঠিক সমাধানটি সবসময় সম্ভব হয় না, সুতরাং আপনি সর্বোপরি যাদু মান ব্যবহার করে শেষ করতে পারেন, তবে আপনি যখন করেন, আপনাকে প্রতি কেস ভিত্তিতে উপযুক্ত মান সম্পর্কে সিদ্ধান্ত নিতে হবে, কারণ কোন তারিখগুলি করে এবং না করে বোধগম্যতা আপনি যে ডোমেনটির মডেলিং করছেন তার উপর নির্ভর করে - আপনি যদি লগের টাইমস্ট্যাম্পগুলি সংরক্ষণ করেন, 01/01/2999 একটি যুক্তিসঙ্গত "সময়ের শেষ"; আপনার অ্যাপ্লিকেশন পাওয়ার সম্ভাবনাগুলি এখন থেকে প্রায় 1000 বছর পরে ব্যবহার করা হচ্ছে, আমি মনে করি, কার্যত শূন্য। অনুরূপ বিবেচনা ক্যালেন্ডার অ্যাপ্লিকেশন জন্য যেতে। তবে যদি আপনার সফ্টওয়্যারটি বৈজ্ঞানিক ডেটা পরিচালনা করতে হয় তবে বলুন, পৃথিবীর জলবায়ু সম্পর্কে দীর্ঘমেয়াদী ভবিষ্যদ্বাণী? এগুলি প্রকৃতপক্ষে ভবিষ্যতের হাজার বছরের দিকে চেয়ে থাকতে পারে। অথবা এটি আরও একধাপ এগিয়ে নেওয়া; জ্যোতির্বিজ্ঞান, এমন এক ক্ষেত্র যেখানে বিলিয়ন বছর ধরে আদেশের ভিত্তিতে খুব বড় টাইমস্প্যানগুলিতে যুক্তি করা একেবারে স্বাভাবিক, উভয় পথে এবং ভবিষ্যতে। তাদের জন্য, 01/01/2999 একটি নিখুঁত হাস্যকর স্বেচ্ছাচারিতা সর্বাধিক। ওটিওএইচ, ক্যালেন্ডার সিস্টেম যা ভবিষ্যতে দশ ট্রিলিয়ন বছর ধরে টাইমস্প্যানগুলি পরিচালনা করতে সক্ষম হয় কেবলমাত্র স্টোরেজ ক্ষমতার কারণে ডেন্টিস্ট অ্যাপয়েন্টমেন্ট ট্র্যাকিং সিস্টেমের জন্য খুব কমই কার্যকর।

অন্য কথায়, একটি মান যা ভুল এবং স্বেচ্ছাসেবী দ্বারা সংজ্ঞা দিয়ে শুরু করার জন্য সর্বোত্তম পছন্দ নেই। এ কারণেই কোনও প্রোগ্রামিং ভাষার সংজ্ঞায়িত একজনকে দেখা সত্যিই অস্বাভাবিক; যাঁরা সাধারণত এটি "সময়ের সমাপ্তি" নামকরণ করেন না, বরং কিছু DATE_MAX(বা Date.MAX) এর মতো করেন এবং এটি "সময়ের শেষ" নয়, "তারিখের ডেটাটাইপে সংরক্ষণ করা যায় এমন বৃহত্তম মান" অর্থ বোঝায় or "অনির্দিষ্টকালের জন্য"।

Comments

একটি বিশেষ মান বোঝার জন্য নাল ব্যবহার করা সেই বিশেষ মানটি ব্যবহার করার চেয়ে সত্যিকারের চেয়ে ভাল কিছু নয়

— রাইথাল

@ রাইথাল আচ্ছা, আমার মনে হয় 'নুলেনিয়াম' বাগ নেই, তাই এটি কমপক্ষে আরও খানিকটা ভাল ...

— কে.স্টেফ

@ রাইঠাল: আসলে তা নয়। এমন অনেকগুলি ক্রিয়া রয়েছে যা আপনি যাদু সংখ্যায় সঞ্চালন করতে পারেন যা আপনি নালার উপর সম্পাদন করতে পারবেন না।

— পিটার বি

@ রাইথাল - এক্ষেত্রে nullএকটি বিশেষ মান হিসাবে ব্যবহৃত হচ্ছে না, এটির সঠিক অর্থ হিসাবে ব্যবহৃত হচ্ছে null, যা "অনুপস্থিত"। সুতরাং যদি আপনার ক্ষেত্রটি হয় ExpiryDate, যা আরও সঠিক: null(যার অর্থ মেয়াদ শেষ হওয়ার তারিখ নেই) বা END_OF_TIME(যার অস্তিত্ব নেই, যতদূর আমরা জানি)। স্পষ্টতই nullবা এর NoValueঅনুরূপ কিছু হ'ল আরও ভাল সমাধান।

— স্কট হুইটলক

@ জওয়ান্টিং - তাদের মধ্যে কোনও পার্থক্য নেই কারণ একটি নেই। নুল অর্থ এর অস্তিত্ব নেই বা আরও বেশি মানুষের শর্তে মানটি সংজ্ঞায়িত হয় না।

— রামহাউন্ড

Answer 2

একটি শিল্প হিসাবে আমরা কয়েকটি বাইট যেমন সংরক্ষণের তাগিদে কুখ্যাতভাবে স্বল্পদৃষ্টি এবং স্বেচ্ছাচারী হয়েছি

• 31 ডিসেম্বর 99
• 1938 জানুয়ারী
• টি + 50 বছর, যখন আশা করা যায় যে আমি জড়িত সমস্ত সিস্টেমগুলি অচল হয়ে গেছে বা প্রতিস্থাপন করা হয়েছে (বা আমি মারা গেছি, যেটি প্রথমে আসে)।

আইএমএইচও সবচেয়ে ভাল বাজি হ'ল 'সর্বোচ্চ তারিখ' -র জন্য উপযুক্ত, মূলধারার স্তরের বিমূর্ততার সাথে থাকা এবং আশা করি যে সময়টি আসার আগেই একটি সাধারণ সমাধান সমস্যার সমাধান করেছে।

যেমন। নেট, ডেটটাইম.ম্যাক্সভ্যালু নির্বিচারে 23:59:59.9999999, December 31, 9999, exactly one 100-nanosecond tick before 00:00:00, January 1, 10000। সুতরাং যদি আমার নিজের দীর্ঘায়ু সম্পর্কে আমার অনুমানগুলি মিথ্যা হয় এবং 10000 বছর আগত হয় তবে আমি বরং প্রত্যাশা করি যে ফ্রেমওয়ার্কটির পরবর্তী সংস্করণ সহ আমার অ্যাপ্লিকেশনটির পুনঃব্যবস্থাটি DateTime.MaxValue(যেমন এর অন্তর্নিহিত ধরণের পরিবর্তন করে) একটি নতুন স্বেচ্ছাসেবী মানতে প্রসারিত হবে এবং আরও কয়েক সহস্রাব্দের জন্য রাস্তায় সমস্যাটি আরও লাথি মেরে দিন।

সম্পাদন করা

(টিডামার্সের পয়েন্টকে শক্তিশালী করা যে কোনও কৃত্রিম তারিখের পরিবর্তে ফজিংয়ের পরিবর্তে ভোক্তার কাছে স্পষ্টভাবে এই বিষয়টি তুলে ধরা আরও সঠিক যে আমাদের শেষের তারিখ নেই))

ব্যবহারের বিকল্প হিসাবে null, যা কোনও রেফারেন্স ধরণের (। নেট 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

Duh। আমি অন্ধ। কিছু মনে করো না.

— অট--

একদিন, সম্ভবত। আমাদের কাছে তারিখ এবং সময়গুলির জন্য উইলিয়াম কাহান থাকবে । আমাদের কাছে ইতিবাচক এবং নেতিবাচক অসীম টাইমস্ট্যাম্প, " NaT" মান ইত্যাদির

— রস প্যাটারসন

সাহায্য করতে পারে না তবে এটির

— জুলিয়া

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 বিট আইইই 7575 ডাবল স্পষ্টতা ভাসমান পয়েন্ট নম্বর হিসাবে সংরক্ষণ করুন এবং আপনি ব্যবহার করতে পারেন +INF। একক নির্ভুলতা ব্যবহার করবেন না, এটি কেবলমাত্র 7 ডিজিটের সঠিক যা একটি তারিখের জন্য কিছুটা কম।

Answer 5

কোকো / অবজেক্টিভ-সিতে কারখানার পদ্ধতি রয়েছে [এনএসডিট ডিস্ট্যান্টপাস্ট] এবং [এনএসডিট ডিস্ট্যান্টফিউচার] যা আপনি উল্লেখ করছেন ঠিক সেই ধরণের উপস্থাপন করে।

বর্তমান বাস্তবায়নের মাধ্যমে ফিরে আসা মানগুলি 0 এডি এবং 4000 এডি সার্কিটাকে প্রতিনিধিত্বকারী ধ্রুবক, যদিও এগুলি গ্যারান্টিযুক্ত বা নথিভুক্ত নয়।

Answer 6

সাধারণত এটির কোনও মান নেই, কারণ এটি ভাষা নির্মাণ হিসাবে কার্যকর হবে না।

MAX_INTএবং এটি স্বজনরা একটি উদ্দেশ্য পরিবেশন করে। এগুলি আপনার কোডে ওভারফ্লো বিরুদ্ধে পরীক্ষা করতে ব্যবহার করা যেতে পারে। আপনি যদি অ্যারে, ভেক্টরগুলিতে যাই হোক না কেন বড় ডেটা অবজেক্ট তৈরি এবং পরিচালনা করতে যাচ্ছেন এটি দরকারী। এটি মোটামুটি প্ল্যাটফর্ম-নির্দিষ্ট মান।

একটি MAX_DATEমানের জন্য ব্যবহারের কেস দেখতে আরও কঠিন। সাধারণত এগুলি হ'ল মান, এগুলি প্রোগ্রামের কাঠামোর অংশ হিসাবে ব্যবহৃত হয় না এবং তাই চারপাশের মানটি প্রোগ্রামের বিপর্যয়কর পরিণতি ঘটাতে পারে না (যদিও এটি ডেটা হতে পারে)। এছাড়াও, সি, সি ++ ইত্যাদিতে তারিখ এবং সময়ের ধরণগুলি সাধারণত আরও কঠোরভাবে সংজ্ঞায়িত হয়; এবং তাই প্রোগ্রামটি লেখার লোকদের চিন্তা করার দরকার নেই যে এটি প্ল্যাটফর্মগুলির মধ্যে পরিবর্তিত হতে পারে।

Answer 7

আমাদের করা একটি প্রকল্পে, আমাদের এমন পরিস্থিতি হয়েছিল যেখানে সফ্টওয়্যারটি ব্যবহারের ৩০ বছর পরে টেকসই হবে না এমন কিছু উপাত্ত আকার নির্ধারণ করা হয়েছিল। ক্লায়েন্ট যখন আমাদের নেতৃত্ব প্রকৌশলীকে জিজ্ঞাসা করেছিল: "আচ্ছা, আপনার সফটওয়্যারটি ব্যবহারের 30 বছর পরে আমরা কী করব?" আমাদের সীসা ইঞ্জিনিয়ার, শসা হিসাবে শীতল, একটি সঙ্কুচিত জবাব দিয়েছিল: "আমরা গিয়ে বিয়ার করব!"

মুল বক্তব্যটি হ'ল, কেবলমাত্র সেই তারিখটি ব্যবহার করুন যা ভবিষ্যতে যথেষ্ট যথেষ্ট। আপনার সফ্টওয়্যারটি ততক্ষণে আপগ্রেড বা প্রতিস্থাপন করা হবে এমন সম্ভাবনা রয়েছে। :)