Unix समय 1.7 अरब तक पहुँचा

मूल लेख ↗ Hacker News चर्चा ↗

Unix time हाल ही में अपने epoch, 1 जनवरी 1970, के बाद 1.7 अरब सेकंड पार कर गया, और प्रोग्रामरों ने इस क्षण को scripts, livestreams, और हल्की-फुल्की numerology के साथ चिह्नित किया। एक round number की novelty से आगे बढ़कर, योगदानकर्ता इस मील के पत्थर का उपयोग leap seconds, UTC, TAI और अन्य time standards के बीच के अंतर, और 32-bit timestamps के लिए Year 2038 की looming समस्या जैसे गहरे विषयों को समझने के लिए करते हैं। कई लोग नोट करते हैं कि ये दोहराते हुए epoch milestones timestamps के साथ क़रीबी काम करने वाले लोगों के लिए एक तरह का लंबे समय का metronome बनते हैं।

मील का पत्थर और प्रतिक्रियाएँ

  • Unix time 1970-01-01 के बाद से 1,700,000,000 सेकंड तक पहुँचा, जिससे चंचल “celebration” पोस्ट्स और पहले के मील के पत्थरों (1.2B, 1.4B, 1.5B, 1.6B, 1.666…B, 1.6G, 1.5G, 1400000000, 1234567890, 1,000,000,000) की यादें ताज़ा हुईं।
  • कुछ टिप्पणीकर्ताओं को यह मज़ेदार “numerology” लगता है और वे इन्हें दुर्लभ, लंबे समय के metronome क्षण मानते हैं, यहाँ तक कि इन्हें जन्मदिनों या निजी यादों से जोड़ते हैं।
  • अन्य लोग इसे नज़रअंदाज़ करते हैं और सवाल उठाते हैं कि base-10 का एक round-ish number क्यों मायने रखता है, खासकर जब ऐसे ही thresholds हर लगभग 3 साल में आते हैं।

रोलओवर को देखना

  • लोगों ने shell loops (date +%s, watch), Node.js, Deno REPL, और ad hoc JS snippets (जिनमें setInterval, async generators, drift-correcting timers) शामिल थे, का उपयोग करके काउंटर को टिक करते देखा।
  • कुछ लोगों ने इस घटना को रिकॉर्ड किया या livestream किया; दूसरों ने “clinking calculators” या replay के लिए फिल्माने के बारे में मज़ाक किया।

लीप सेकंड, UTC, और Unix time असल में क्या है

  • इस पर विस्तृत बहस हुई कि Unix time “seconds since epoch” है या “days×86400+seconds”, इस बात पर ज़ोर देते हुए कि POSIX इसे leap seconds को नज़रअंदाज़ करने वाला एक approximation मानता है।
  • यह स्पष्ट किया गया कि:
    • Leap seconds का मतलब है कि कुछ वास्तविक दिन 86401 सेकंड के होते हैं, लेकिन Unix time 86400 मानता है।
    • इससे Unix time वास्तविक बीते हुए SI seconds और TAI से अलग हो जाता है।
    • Unix time में leap second के लिए अलग मान नहीं होते; कुछ timestamps वास्तविक 2-second intervals पर map करते हैं।
  • अलग-अलग time standards और उपयोग मामलों पर चर्चा हुई: मानव गतिविधि के लिए UTC, monotonic time के लिए TAI/Unix/GPS, और astronomy तथा navigation के लिए UT1/apparent solar/sidereal/TCB।
  • यह भी नोट किया गया कि UTC की leap-second नीति पर फिर से विचार किया जा रहा है; भविष्य के “leap minutes” का उल्लेख किया गया है।

भविष्य के मील के पत्थर और 2038 की समस्या

  • लोग आने वाले मील के पत्थरों की ओर इशारा करते हैं: 2027 में 1.8B, 2033 में 2.0B, 2,147,483,647 (signed 32-bit max) और 2,147,483,648।
  • 2038 problem को “next Y2K” के रूप में चर्चा किया गया: आधुनिक सिस्टम अधिकतर 64-bit timestamps का उपयोग करते हैं, लेकिन legacy 32-bit और embedded devices (ROM-burned code सहित) अभी भी चिंता का विषय हैं।
  • कुछ लोग Y2K को एक वास्तविक engineering effort और साथ ही overhyped doomsday दोनों के रूप में याद करते हैं; नोट करते हैं कि डर कभी-कभी systems को ठीक कराने में मदद करता है।

Epochs, calendars, और representation के विवरण

  • 1970 बनाम “year 1” को epoch के रूप में इस्तेमाल करने पर बहस हुई; दूसरों ने नोट किया कि कई calendar eras मौजूद हैं और Gregorian year numbering स्वयं मनमाना है।
  • उल्लेख किया गया कि Go की time representation year 1 का उपयोग करती है और बहुत शुरुआती मशीनों के लिए year-1 epoch अव्यावहारिक था।
  • एक टिप्पणीकार correctness के लिए Unix time की बजाय TAI का ज़ोरदार समर्थन करता है।
  • Protobuf guidance: timestamps के लिए variable-length integers से बचें; fixed-size (fixed32/fixed64) अक्सर छोटे और तेज़ होते हैं।