Epoch के बाद बीता समय

 (aphyr.com)
2 पॉइंट द्वारा GN⁺ 2024-12-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • POSIX time/Unix time को अक्सर 1970-01-01 00:00:00 के बाद के सेकंडों की संख्या कहा जाता है, लेकिन असल में यह UTC-आधारित value है जो leap seconds को अनदेखा करती है, इसलिए वास्तविक बीते सेकंडों से मेल नहीं खाती
  • 2024-12-25 18:51:26 UTC के आधार पर POSIX time 1735152686 है, जबकि epoch के बाद वास्तविक बीते सेकंड 1735152713 हैं, यानी 27 सेकंड का अंतर
  • IEEE 1003.1 seconds since the Epoch को परिभाषित करते समय एक दिन को हमेशा 86,400 सेकंड मानकर गणना करता है, और standard का appendix भी compatibility और calculation की सुविधा के लिए 1970 के बाद जोड़े गए 14 leap seconds को अनदेखा करता है
  • UTC में solar day से अंतर कम करने के लिए leap seconds जोड़े जाते हैं, और इस दौरान POSIX time पीछे jump करता है, जिससे Linux, Qantas, Cloudflare DNS जैसे outage cases हुए हैं
  • एक ही computer पर time interval मापने के लिए CLOCK_MONOTONIC या CLOCK_BOOTTIME बेहतर हैं, और अगर POSIX timestamp से मिलाना जरूरी हो तो leap smear या POSIX↔TAI conversion पर विचार करना चाहिए

POSIX time वास्तविक बीते सेकंडों की संख्या नहीं है

  • JavaScript Date, GNU coreutils, Linux time(2), Go time.Unix, MySQL datetime, Ruby Time, Cassandra timestamp आदि POSIX time को अक्सर Unix epoch के बाद के सेकंडों की संख्या की तरह扱ते हैं
  • लेकिन यह expression आम intuition से पूरी तरह मेल नहीं खाता
    • उदाहरण समय: 2024-12-25 18:51:26 UTC
    • POSIX time: 1735152686
    • POSIX epoch के बाद वास्तविक बीते सेकंड: 1735152713
    • अंतर: 27 सेकंड
  • यह अंतर इसलिए पैदा होता है क्योंकि POSIX time IEEE 1003.1 में UTC से derive होने के बावजूद, हर दिन को ठीक 86,400 सेकंड मानता है
  • standard में seconds since the Epoch की definition tm_sec, tm_min, tm_hour, tm_yday, tm_year का उपयोग करके value calculate करती है, और 1970 से पहले के years या negative values के साथ relationship को define नहीं करती
  • वास्तविक दिन की length हमेशा 86,400 सेकंड नहीं होती और समय के साथ बदलती है
    • UTC date solar day से बहुत दूर न चली जाए, इसलिए astronomers periodically leap second घोषित करते हैं
    • नतीजतन POSIX time हर कुछ साल में पीछे jump कर सकता है
    • कभी आगे भी jump कर सकता है
  • leap seconds वास्तविक outages का कारण बने हैं

standard का compromise और practical alternatives

  • IEEE 1003 appendix B बताता है कि standard प्रकाशित होने के समय 1970-01-01 के बाद 14 leap seconds जोड़े जा चुके थे, लेकिन आसान calculation और compatibility के लिए इन 14 seconds को ignore किया गया
  • standard मानता है कि ज्यादातर systems में “time” value लगातार बढ़ती है, और उसने यह पक्ष चुना कि leap second के दौरान भी यह value बढ़नी चाहिए
    • साथ ही यह मानकर चलता है कि ज्यादातर systems leap seconds track नहीं करते या standard time reference से synchronized नहीं हो सकते
    • इसलिए यह requirement नहीं रखता कि seconds since the Epoch reference time और epoch के बीच के exact seconds को अनिवार्य रूप से दर्शाए
    • उसका रुख यह है कि applications इस value को epoch के बाद seconds की संख्या की तरह treat कर सकें, इतना पर्याप्त है; जरूरी accuracy system vendors और administrators को संभालनी चाहिए
  • distributed applications में timestamp से events synchronize किए जाते हैं, इसलिए consistent interpretation महत्वपूर्ण हो सकती है
    • leap seconds का accumulation predict नहीं किया जा सकता
    • epoch के बाद leap seconds की संख्या बढ़ने की संभावना है
    • standard को astronomically short duration वाली applications के बीच time synchronization में ज्यादा रुचि है
  • वास्तविक systems समय थोड़ा mismatch होने पर भी आम तौर पर काम करते हैं, लेकिन leap seconds दुर्लभ हैं और “epoch के बाद seconds की संख्या” वाली linear intuition मजबूत है, इसलिए undiscovered bugs जमा हो सकते हैं
  • स्थिति के हिसाब से alternatives ये हैं
    • एक computer पर दो events के बीच केवल duration calculate करनी हो तो CLOCK_MONOTONIC, और उससे भी आगे CLOCK_BOOTTIME इस्तेमाल करें
    • अगर POSIX time मानने वाले दूसरे systems के साथ timestamp exchange करने की जरूरत नहीं है, तो TAI, GPS, LORAN इस्तेमाल करें
    • POSIX timestamp systems से roughly align करना हो तो leap smear के जरिए leap second को लंबे time interval में distribute करें
    • qntm की t-a-i जैसी library से POSIX और TAI के बीच conversion संभव है
  • leap seconds को abolish करने की कोशिशें चल रही हैं, और 2035 तक इनके साकार होने की उम्मीद है
    • एक दिन 86,400 सेकंड assumption पर निर्भर हर चीज में conversion table डालने का अतिरिक्त काम जरूरी होगा
    • 2035 के बाद के समयों के लिए “दो समयों के बीच कितने seconds हैं” जैसे सवाल काफी सरल हो सकते हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-12-27
Hacker News टिप्पणियाँ

  • मैंने अभी Vernor Vinge का 2000 का SF उपन्यास A Deepness in the Sky पढ़ा, और यह एक शानदार किताब है जिसमें epoch के बाद के सेकंड (seconds since the epoch) का एक अप्रत्याशित ज़िक्र आता है
    यह “Traders के समय मापने के तरीके को देखिए…” से शुरू होकर बताता है कि Qeng Ho मानवता द्वारा Old Earth के चाँद पर पहली बार कदम रखने के क्षण से सेकंड गिनते हैं, लेकिन और ध्यान से देखें तो शुरुआती बिंदु असल में लगभग 1.5 करोड़ सेकंड बाद है—मानवता के शुरुआती कंप्यूटर operating systems में से एक का 0 सेकंड

    • यह किताब निजी तौर पर मेरी all-time favorites में से एक है, और जिस तरह इसमें सूक्ष्म software references इस्तेमाल किए गए हैं, वह मुझे बहुत पसंद है
      अगर आप “अंतरिक्ष में computer science” और चाहते हैं तो Bobiverse series सुझाऊँगा, और “इंसान + simulation + computer” की और खोज चाहते हैं तो Permutation City

  • समय मापन के बारे में जब भी पढ़ता हूँ, हर बार कुछ नया सीखता हूँ। मैं सोचता था कि rollover को छोड़ दें तो Unix time समय track करने का सबसे सरल तरीका है, और leap seconds के बारे में जानता था, लेकिन यह नहीं सोचा था कि वे यहाँ भी लागू होते हैं
    “UTC, GPS, LORAN and TAI” लिंक भी पढ़ा, और यह दिलचस्प तुलना है कि GPS time leap seconds को reflect नहीं करता

    • यह कहना सरल है कि कोई घटना कितने सेकंड पहले/बाद हुई। मुश्किल हिस्सा उस क्षण को calendar date देना है
    • निष्कर्ष में, मुझे लगता है कि TAI सबसे सरल है, और बाकी formats को जरूरत पड़ने पर TAI से convert करके इस्तेमाल करना चाहिए—जैसे display या interoperability के लिए

  • “2035 तक leap seconds हटाने की कोशिश चल रही है” वाली योजना मुझे खास पसंद नहीं है
    UTC का मूल उद्देश्य TAI से पूर्णांक सेकंड की दूरी पर रहकर mean solar time (MST) के करीब रहना है। अगर अब MST को track नहीं करना है, तो सीधे TAI पर switch करना चाहिए
    UTC को MST से दूर जाने देने पर, पुराने leap seconds फिर भी संभालने पड़ेंगे, लेकिन वे leap seconds अब किसी उद्देश्य के बिना एक अधकचरी स्थिति बन जाएँगे

    • मैं सहमत हूँ कि MST से हटने की लागत उससे मिलने वाले लाभ से ज्यादा है
      हालांकि यह प्रस्ताव पूरी तरह अर्थहीन नहीं है। इसका उद्देश्य मौजूदा UTC time management को बदले बिना, 2035 के बाद के दो timestamps के बीच का अंतर ठीक-ठीक वास्तविक physical seconds की संख्या बनाना है
      फिर भी, जब MST पहले से ही UTC का एक feature है, तो उसे हटाना अजीब लगता है
    • आदर्श दुनिया में computer systems को time tracking के लिए TAI इस्तेमाल करना चाहिए था, और TZ database का उपयोग करके UTC या local time में convert करना चाहिए था
      लेकिन वास्तविकता में कई systems ने गलत चुनाव किया, और खासकर UNIX सबसे बड़ा कारण है। वह चुनाव इतने सारे systems और regulations में गहराई तक धँस चुका है कि “बस TAI पर switch कर दो” व्यावहारिक रूप से असंभव है
      इसलिए UTC को “नया TAI” मानकर reinterpret करना आसान है। किसी दिन पुराना UTC किसी और नाम से फिर सामने आ जाए तो हैरानी नहीं होगी
    • TAI नाम की कोई अलग इकाई नहीं है। UTC से शुरू करके जिन leap seconds में आपकी रुचि है उनकी संख्या घटाएँ, तो जो मिलता है वही TAI है। TAI को किसी अलग standard quantity के रूप में maintain नहीं किया जाता
      अधिकतर या सभी देशों में civil time UTC पर आधारित है। सिर्फ इसलिए कि यह थोड़ा अधिक शुद्ध है, दुनिया भर की घड़ियों को करीब 30 सेकंड पीछे नहीं किया जाएगा
      GPS time का भी TAI से offset है, लेकिन कोई खास परवाह नहीं करता। Unix epoch भी ऐसा ही है; नतीजा consistent रहे तो काफी है
    • Hack सचमुच मामूली है। महीने में एक बार जाँचें कि UTC # ET है या नहीं, और अगर अलग हो तो Leap_Second नाम की file बना दें। हर महीने देखें कि यह file मौजूद है या नहीं; अगर है तो उसे delete करें, Leap_Seconds file के value में 1 जोड़ें और LSSE नाम का backup बना दें
      “You are not expected to understand this.” यह दोनों systems को बनाए रखने का तरीका है। चाहें तो hash या lookup table से भी बनाया जा सकता है

  • यह भी महत्वपूर्ण है कि आधुनिक UTC epoch 1 जनवरी 1972 है। उससे पहले UTC, TAI से अलग second length इस्तेमाल करता था
    1971 के अंत में intermediate step के तौर पर ठीक 0.107758 TAI seconds का आखिरी irregular jump था, और 1958–1971 के दौरान UTC या TAI के छोटे time steps और frequency adjustments का कुल योग ठीक 10 seconds बने, ऐसा मिलाया गया। इसलिए 1 जनवरी 1972 00:00:00 UTC ठीक 1 जनवरी 1972 00:00:10 TAI था, और उसके बाद से अंतर integer seconds का हो गया
    उसी समय UTC की tick rate ठीक TAI जैसी हो गई, और UTC ने UT2 के बजाय UT1 को track करना शुरू किया। इसलिए 1970 और 1971 का Unix time उस अवधि के वास्तविक UTC time से मेल नहीं खाता
    https://en.wikipedia.org/wiki/Coordinated_Universal_Time#His...
    https://en.wikipedia.org/wiki/Unix_time#UTC_basis

    • इसी वजह से आज जीवित लोगों में कुछ ऐसे हैं जिन्हें अपनी सटीक उम्र (सेकंड में) पता नहीं हो सकती और आगे भी नहीं हो सकेगी
      यह मान लेने पर भी कि birth certificate में समय सेकंड तक सटीक है। क्योंकि उनके जीवन के एक हिस्से में “1 सेकंड की लंबाई” मानी गई value, आज हम आम तौर पर जिस 1 सेकंड के बारे में सोचते हैं, उससे काफी अलग थी
      यहाँ second से मतलब caesium-133 atom की unperturbed ground-state hyperfine transition frequency 9,192,631,770/s पर आधारित second से है

  • हाल ही में मैंने किसी exchange के लिए कुछ कोड लिखा था, और वह सिस्टम VAX, या सही कहें तो OpenVMS, पर चलता था और उसका epoch 17 नवंबर 1858 था
    अपने करियर में पहली बार मैंने Unix से अलग epoch देखा था, और गनीमत थी कि इस्तेमाल हो रहे कोड में इसे Unix epoch के रूप में abstract कर दिया गया था

    • लगता है 1858 वाला epoch खगोलीय standard calendar Julian Day से आया है। इसमें दिन 0 ईसा पूर्व 4713 है
      https://www.slac.stanford.edu/~rkj/crazytime.txt
      1950 के दशक के computer memory में इन तारीखों को फिट करने के लिए calendar को 24 लाख दिनों से offset किया गया, और नतीजतन दिन 0, 17 नवंबर 1858 बन गया
    • Excel के epoch 1 जनवरी 1900 और Basic के 31 दिसंबर 1899 के टकराव के बारे में एक पुराना Microsoft किस्सा भी है
      https://www.joelonsoftware.com/2006/06/16/my-first-billg-rev...
    • जानने लायक एक और आम computing system: Windows epoch 1 जनवरी 1601 है
    • Classic MacOS, Apple का HFS file system (OS X में भी इस्तेमाल हुआ), और PalmOS—इन सभी का epoch 1 जनवरी 1904 था
      macOS/Swift Foundation API NSDate.timeIntervalSinceReferenceDate 1 जनवरी 2001 को epoch के रूप में इस्तेमाल करता है
      Wikipedia पर एक उपयोगी सूची भी है: https://en.wikipedia.org/wiki/Epoch_(computing)#Notable_epoc...
    • PostgreSQL internally timestamp store करने के लिए 2000-01-01 epoch इस्तेमाल करता है

  • कुछ समय-बिंदु POSIX timestamp से व्यक्त नहीं किए जा सकते, और कुछ POSIX timestamp वास्तविक समय से मेल नहीं खाते

    • जिज्ञासा है कि ऐसे कौन से POSIX timestamp हैं जो वास्तविक समय से मेल नहीं खाते। या क्या यह भविष्य में negative leap second होने की स्थिति की बात है?
    • यह हमेशा से ऐसा ही रहा है। Unix time में 1970 से पहले का समय defined नहीं है
    • फिर भी कम-से-कम कोई एक POSIX timestamp दो या अधिक वास्तविक समय-बिंदुओं से तो मेल नहीं खाता। यह उस एक representation से बेहतर है जिसे लोग हर चीज़ में इस्तेमाल करते हैं
    • ऐसा नहीं है
      यह कुछ ऐसा कहने जैसा है कि कुछ time instants के लिए ISO 8601 year नहीं होता। हर instant का year होता है, बस कुछ years दूसरों से लंबे होते हैं
      अगर आप बैठकर https://time.is/UTC देखते रहें, तो time monotonically बढ़ेगा, बस कभी-कभी कोई second बहुत थोड़ा लंबा हो जाएगा। जैसे 24 घंटे में करीब 0.001% ज्यादा लंबा

  • database में date store करते समय हमेशा Unix epoch time के रूप में store करता हूं, और date field में timezone information record नहीं करता। अगर timezone जानने की requirement हो, तो उसे अलग store करता हूं
    सोच रहा हूं कि क्या इसके बजाय timestamp को TAI format में store करना चाहिए, और जरूरत पड़ने पर UTC में convert करने वाले function से earth-related corrections handle करने चाहिए
    पता है कि timezone एक minefield है, लेकिन वह भी इंसानों की बनाई चीज़ है जिसकी boundaries समय के साथ बदलती रहती हैं। लगता है absolute time पर fix करके जरूरत पड़ने पर desired local time format में render करना चाहिए

    • सही। TAI या उससे मिलता-जुलता format “system” time track करने का इकलौता reasonable तरीका है, और higher-level systems को इसे इंसानों द्वारा देखे जाने वाले time में convert करना चाहिए
      leap second adjustment उसी जगह होना चाहिए जहां timezone conversion होता है। दुर्भाग्य से Unix ने गलत चीज़ standardize कर दी, और migration मुश्किल है
    • ज्यादातर नहीं, बल्कि लगभग कभी नहीं। अधिकांश software leap seconds को smear/cover करके handle करने के लिए लिखा गया है, और वास्तव में यह केवल clock synchronization layer में होता है। उदाहरण के लिए chrony leap second smearing implement करता है
      इसलिए सारी clocks वैसे भी UTC से synchronized होती हैं। store करते समय UTC से TAI में convert करना और पढ़ते समय वापस convert करना पड़ेगा, जिससे गड़बड़ हो जाएगी
    • “date field में timezone information record नहीं करता” वाली बात पर, असल में timestamp column में timezone preservation enable करने वाले databases बहुत कम हैं
      आम तौर पर database में stored timestamp के लिए timezone की कोई concept नहीं होती (SQL Server), या वह “timezone-aware” timestamp type देता है लेकिन input को UTC में convert करके original timezone छोड़ देता है (MySQL, Postgres)
      जहां तक मुझे पता है, केवल Oracle ही with time zone type में local नहीं बल्कि actual timezone को round-trip preserve कर सकता है
    • यह इस पर निर्भर करता है कि system क्या store करता है। अधिकांश systems को कुछ साल में एक बार 1 second गलत होने से फर्क नहीं पड़ता
      कुछ calculations में 1 second का फर्क बड़ा मुद्दा होता है। सबसे widely used format से अलग कुछ अपनाते समय सावधान रहना चाहिए, और standard से हटने की ठोस वजह होनी चाहिए। सिर्फ अलग होना ही cost बढ़ा सकता है
    • database के native date-time fields इस्तेमाल कर लेने चाहिए

  • इस लेख ने तो जैसे Christmas खराब कर दिया। क्या कुछ भी sacred नहीं है? seconds तो epoch के बाद के seconds होने चाहिए
    solar day से थोड़ा-सा drift करने की परवाह क्यों करनी चाहिए, समझ नहीं आता। epoch के बाद के seconds को date representation में बदलने वाला converter correction की जिम्मेदारी ले सकता है, है न?

    • मौजूदा तरीका असल में वही है जो हम चाहते हैं। 86400 seconds = 1 day, और हम इस assumption पर काम करते हैं कि UTC midnight हमेशा 86400 का multiple होता है
      मैं नहीं चाहता कि सारे software leap seconds को hardcode करें, smearing handle करें, और नया leap second introduce होने पर एक महीने के अंदर update method मांगें
      अब तक हमें इसकी चिंता या इसके बारे में सोचना नहीं पड़ा, और आगे भी जरूरत नहीं है। इसे सही तरीके से handle किया जा रहा है

  • leap seconds की जगह equator पर लगाए गए बड़े rockets होने चाहिए। clocks adjust मत करो, planet adjust करो

    • अगर calculation की गलती से Earth बहुत slow या बहुत fast हो जाए तो शायद यह उतना मजेदार नहीं रहेगा
      Islamic tradition में end times और Antichrist (Dajjal) के बारे में कहानियों में भी ऐसी चीज़ सचमुच होने जैसी बात आती है। कहा जाता है, “Antichrist का पहला दिन एक साल जैसा होगा, दूसरा दिन एक महीने जैसा, और तीसरा दिन एक हफ्ते जैसा,” और कई लोग इसे literal रूप में लेते हैं—यानी Earth का rotation सचमुच slow हो जाएगा और आखिर direction reverse हो जाएगी, जिससे सूरज west से उगेगा। वही मानवता के अंत का आखिरी sign होगा

  • लीप सेकंड की वजह से epoch date +%s के संकेत से 29 सेकंड और ज़्यादा पहले हो जाए, तो भी इससे क्या फर्क पड़ता है, ऐसा लगता है
    यह तथ्य कहीं ज़्यादा महत्वपूर्ण है कि मौजूदा समय को दर्शाने वाले किसी नंबर N पर सभी सहमत हैं। काल्पनिक -29 सेकंड वास्तविक दुनिया पर असर नहीं डालते। हम 30 साल पुराने लक्ष्य पर मिसाइल निशाना लगाने वाला routine तो चलाने वाले नहीं हैं, है न
    लीप सेकंड हटाने के पक्ष में हूं, लेकिन समय की असंगति पर ज़ोर देना उपयोगी नहीं लगता। भले ही बारीकी से देखें तो बात सही हो

    • ऐसी स्थिति की कल्पना की जा सकती है जहां किसी छोटी घटना की अवधि शुरू/समाप्ति समय से निकाली जाए। अगर वह अंतराल किसी लीप सेकंड को पार करता है, तो timestamp को संभालने के तरीके के आधार पर अवधि काफी अलग हो सकती है
      इससे भी महत्वपूर्ण बात भविष्य पर असर है। पुराने timestamp साधारण “वर्तमान - N सेकंड” calculation से कुछ सेकंड अलग हो सकते हैं, यह ज़्यादातर एक रोचक तथ्य जैसा है; लेकिन भविष्य में किसी समय सभी घड़ियों को फिर 1 सेकंड shift करना पड़ सकता है, यह अधिक महत्वपूर्ण है। इसे ध्यान में रखने के लिए काफी मेहनत मांगने वाले वास्तविक उदाहरण कई हैं
    • कुछ चीज़ों के लिए यह मायने रखता है। ऐसे काल्पनिक लीप सेकंड न हों, तो उदाहरण के लिए स्थानीय दोपहर में सूर्य की स्थिति 29 सेकंड जितनी खिसक जाएगी