दिसंबर 2026 के अंत में कोई leap second नहीं जोड़ा जाएगा

 (datacenter.iers.org)
1 पॉइंट द्वारा GN⁺ 4 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • IERS Bulletin C 72 के अनुसार दिसंबर 2026 के अंत में UTC में कोई leap second नहीं जोड़ा जाएगा, इसलिए समय मापन और वितरण सिस्टमों को अलग से insertion processing की तैयारी करने की आवश्यकता नहीं है
  • UTC और TAI के बीच का अंतर 1 जनवरी 2017, 0:00 UTC से अगली सूचना तक UTC-TAI = -37 s बना रहेगा
  • leap second लागू किया जाए या नहीं, यह UT1-TAI परिवर्तन के आधार पर तय होता है, और संभावित समय जून के अंत या दिसंबर के अंत हैं
  • Bulletin C हर 6 महीने में UTC time step की घोषणा करता है, या अगली संभावित तारीख पर कोई time step नहीं है इसकी पुष्टि करता है
  • 2026 के अंत में UTC वितरण के लिए किसी नए correction value की आवश्यकता नहीं है, और मौजूदा UTC-TAI = -37 s संबंध का उपयोग जारी रखा जा सकता है

IERS Bulletin C 72 की UTC सूचना

  • IERS द्वारा 6 जुलाई 2026 को Paris में जारी Bulletin C 72 में कहा गया है कि दिसंबर 2026 के अंत में leap second लागू नहीं किया जाएगा
  • यह सूचना वे संस्थान जो समय मापन और वितरण के लिए जिम्मेदार हैं उनके लिए है
  • मुख्य मान निम्नलिखित दो हैं
    • 1 जनवरी 2017, 0:00 UTC से अगली सूचना तक UTC-TAI = -37 s
    • दिसंबर 2026 के अंत में UTC में कोई नया time step नहीं है

leap second का निर्णय और सूचना चक्र

  • leap second को UT1-TAI में परिवर्तन के आधार पर UTC में लागू किया जा सकता है
  • इसे लागू करने के संभावित समय हर वर्ष जून के अंत या दिसंबर के अंत हैं
  • Bulletin C हर 6 महीने में जारी किया जाता है
    • यदि UTC में कोई time step होता है, तो उसकी घोषणा की जाती है
    • यदि अगली संभावित तारीख पर कोई time step नहीं होता, तो इसकी पुष्टि की जाती है

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

1 टिप्पणियां

 
GN⁺ 4 시간 전
Hacker News की राय

  • मुझे जिज्ञासा है कि यह अनिश्चितता आखिर किस वजह से होती है। लगता है कि हमें पृथ्वी के घूर्णन और परिक्रमण के बारे में दशमलव के कई स्थानों तक पता होना चाहिए, तो क्या भूगर्भीय गतिविधि या मौसम जैसे कारक घूर्णन गति में अंतर पैदा करते हैं, इसलिए इसका अनुमान लगाना कठिन होता है?

    • संक्षेप में, हाँ। मौसम, भूगर्भीय गतिविधि, और मानवों द्वारा पानी की आवाजाही जैसे aquifer depletion और dam construction, साथ ही ग्लेशियरों और बर्फ का पिघलना—ये सब पृथ्वी की घूर्णन अवधि और घूर्णन अक्ष में ऐसे बदलाव लाते हैं जिनका अनुमान लगाना कठिन है
      मेरी याद के अनुसार ये मॉडल low-order trigonometric polynomials हैं, इसलिए यदि आप अनिश्चितता को पूरी तरह मॉडल भी कर लें, तब भी truncation error की वजह से इन्हें बहुत अधिक सटीकता के साथ वितरित करना मुश्किल है, और ये पहले से ही satellites जैसी चीज़ों में डाले जा चुके हैं, इसलिए इन्हें मनमाने ढंग से जटिल भी नहीं बनाया जा सकता
      वैसे, leap second जल्द ही समाप्त होने वाला है, और मेरी जानकारी में 2035 में इसे चरणबद्ध रूप से बंद किया जाना है। याद है कि Russia को GLONASS satellites अपडेट करने का समय चाहिए था, इसलिए देरी हुई
    • हाँ। ऐसे कारक और भी बहुत हैं। हमारी measurement precision दिन की लंबाई में साल-दर-साल होने वाले प्रथम और द्वितीय अवकलज परिवर्तनों से कहीं बेहतर है
      https://datacenter.iers.org/singlePlot.php?plotname=Bulletin... इससे सबसे संबंधित graph है, और vertical jumps leap seconds को दिखाते हैं। IERS में rotation के दूसरे आयामों के graph भी हैं, लेकिन यह graph देखने में अच्छा है
    • संयोग से मैं यह देखने के लिए Wikipedia लेख देख रहा था कि आख़िरी leap second कब जोड़ा गया था, और जवाब वहीं है
      “पृथ्वी की घूर्णन गति जलवायु और भूवैज्ञानिक घटनाओं के जवाब में बदलती है, इसलिए UTC leap seconds अनियमित रूप से लगाए जाते हैं और उनका सटीक अनुमान नहीं लगाया जा सकता”
      https://en.wikipedia.org/wiki/Leap_second
    • यह तो लगभग उल्टा है। पृथ्वी का घूर्णन साल-दर-साल कई सेकंड तक बदल सकता है, लेकिन सैकड़ों वर्षों के पैमाने पर ये उतार-चढ़ाव मोटे तौर पर एक-दूसरे को संतुलित कर देते हैं
      इसलिए मुझे नहीं लगता कि leap second जोड़ने या हटाने की कोशिश कोई बहुत अच्छा विचार है। असल में ऐसी चीज़ों की परवाह लगभग केवल space agencies को होती है, और वे अपनी ज़रूरत के हिसाब से correction values लगा सकते हैं; इसका असर सब पर डालने की ज़रूरत नहीं है
      आम लोगों पर इस drift का व्यावहारिक असर शायद GPS तक सीमित है, और GPS पहले से ही अपनी clocks के साथ offset broadcast करता है ताकि receiver उसे ठीक कर सके। GPS clock न तो UTC है और न ही TAI
    • https://en.wikipedia.org/wiki/Leap_second#:~:text=Other%20co... देखें

  • क्या यह दरअसल anti-news नहीं है? मुझे धुंधला-सा याद है कि आजकल के computing systems में यह बहुत ज़्यादा समस्याएँ पैदा करता है, इसलिए अगली अलग सूचना तक leap seconds जोड़ना रोक दिया गया था
    अभी अंतर 37 सेकंड का है, और किसी को यह चिंता करने की ज़रूरत नहीं कि Christmas खिसककर Easter के आसपास पहुँच जाएगा। मुझे लगता है यह उन समस्याओं में से है जिन्हें और कई समस्याओं की तुलना में कहीं अधिक ज़िम्मेदारी से भविष्य की पीढ़ियों को सौंपा जा सकता है
    हर 6 महीने में घोषणा आना सिर्फ मूल अंतरराष्ट्रीय treaty की भाषा के अनुरूप प्रक्रिया निभाने जैसा है

    • अभी ऐसा नहीं हुआ है। यह सिर्फ एक proposal है, और आधिकारिक समाप्ति 2035 से पहले मुश्किल लगती है
      कुछ समय से leap second न होने की वजह यह है कि TAI और UT1 के बीच drift धीमा हो गया है, और वास्तव में बहुत धीरे-धीरे उल्टी दिशा में बढ़ रहा है
    • यह बात बेतुकी लगती है कि notice period सिर्फ 6 महीने का है, और संभव है कि यही समस्या की जड़ हो
      अगर समय ±60 सेकंड तक भी गलत हो जाए तो शायद किसी को पता नहीं चलेगा, इसलिए 10 साल में एक बार कोई मनमाना leap second डालना और 10 साल पहले से घोषणा करना, ताकि सबके पास अपने systems ठीक करने का समय हो, ज़्यादा manageable लगता है। दुनिया भर में इसे coordinated तरीके से लागू करने के लिए 6 महीने बेहद आशावादी हैं

  • अगर 5 साल के बच्चे को समझाने जैसे कहें, तो मैं जानना चाहता हूँ कि इसका UNIX timestamp पर क्या असर पड़ता है। खासकर उन चीज़ों पर जो maintenance mode में हैं या लगभग unmanaged हैं
    मेरे काम में इस स्तर की precision की ज़रूरत नहीं है, लेकिन निश्चित रूप से कुछ क्षेत्रों में इसकी ज़रूरत होगी

    • UNIX timestamp leap seconds को पूरी तरह नज़रअंदाज़ करता है और उन्हें मानो मौजूद ही नहीं मानता
      इसलिए जब leap second डाला जाता है, तो ऐसा physical second हो सकता है जिसे UNIX timestamp से refer नहीं किया जा सकता, और जब leap second हटाया जाता है, तो ऐसे second के लिए UNIX timestamp हो सकता है जो वास्तव में मौजूद ही नहीं है
    • हर बार जब leap second जोड़ा जाता था, Google server clocks को ज़्यादा लंबे समय, आम तौर पर कुछ घंटों में, धीरे या तेज़ चलाकर उन्हें NIST में कहीं मौजूद एक शुद्ध platinum की पूर्ण गोल pendulum clock के साथ धीरे-धीरे फिर से sync करता था: https://developers.google.com/time/smear
    • time() और clock_gettime(CLOCK_REALTIME) के परिणाम leap second से प्रभावित होते हैं
      नया leap second NTP के ज़रिए system तक पहुँचता है। दुर्भाग्य से NTP सिर्फ यह बताने वाला indicator flag वितरित करता है कि leap second आने वाला है; offset खुद वितरित नहीं करता। लेकिन वितरित किया जाने वाला समय स्वयं पहले से leap second से प्रभावित होता है, इसलिए NTP client के लिए उसका अलग से जानना ज़रूरी नहीं है
      इसके उलट GPS और PTP जैसे दूसरे time synchronization तरीके ऐसे time scales इस्तेमाल करते हैं जो leap second से प्रभावित नहीं होते, और UTC offset को अतिरिक्त जानकारी के रूप में वितरित करते हैं। प्राप्त समय को अंत में समायोजित करना client का काम होता है। kernel में leap second के लिए clock_adjtime() parameter मौजूद है
      अगर कोई manually managed system NTP client चला रहा है, तो चलते समय नया leap second आने पर उसका समय बदल जाएगा। Linux UTC time को प्राथमिक मानता है, इसलिए वही RTC device में store होता है और reboot के बाद भी बना रहता है
      CLOCK_TAI ऐसा लगता है कि उसे TAI time लौटाना चाहिए, लेकिन आम Linux desktop/server distributions में offset तक सेट नहीं होता, इसलिए यह CLOCK_REALTIME जैसा ही समय लौटाता है—यानि इसे दूसरे दर्जे जैसा व्यवहार मिलता है
      /etc के भीतर किसी package में शामिल leap second list file होती है, और इस file को update करने के लिए system update चाहिए होता है। मुझे नहीं लगता कि पारंपरिक NTP software इस package को dynamically update करता है। वैसे भी इस file का इस्तेमाल करने वाला software बहुत कम है
      अगर कोई init service script इसे parse करके kernel UTC offset सेट करती हो, तो update होने तक system का CLOCK_TAI बाकी दुनिया से 1 सेकंड पीछे हो सकता है। लेकिन जहाँ तक मुझे पता है, Linux के UTC time पर इसका कोई असर नहीं पड़ता

  • “समय के मापन और वितरण की ज़िम्मेदारी निभाने वाले संस्थानों के लिए” जैसा वाक्यांश अब तक का सबसे ज़्यादा प्रोफेशनल लगता है

    • इससे भी बेहतर बात यह है कि उस संगठन का नाम International Earth Rotation Service है
    • कई वर्षों तक USNO में तरह-तरह के सटीक time products की देखरेख करने वाले नेतृत्व पद का नाम “Director of the Directorate of Time” था
    • यह Douglas Adams के उपन्यास में आने वाली अभिव्यक्ति जैसा लगता है
    • “Director Earth Orientation Center of IERS Observatoire de Paris, France”
      यह पदनाम भी SF जैसा लगता है

  • अगर UTC-TAI offset -37 सेकंड पर बना रहता है, तो इसका मतलब UTC-GPS offset भी -18 सेकंड पर बना रहेगा
    TAI और GPS के बीच हमेशा 19 सेकंड का स्थिर offset रहता है

  • सोच रहा हूँ कि ऐसी स्थिति में Spanner जैसे सिस्टम का क्या होता होगा
    यह सिरदर्द है, या कोई खास बात नहीं?

    • यह बड़ी समस्या है। इसे संभालने का सबसे आम तरीका smearing कहलाता है, जिसमें “leap second” से पहले के 24 घंटों के दौरान हर सेकंड की लंबाई समायोजित की जाती है
      जिन सिस्टमों में कड़ी ordering guarantee चाहिए, वहाँ हर डिवाइस global clock के साथ sync बनाए रखता है, और सिर्फ clock cycle की लंबाई बहुत थोड़ा बदलती है, इसलिए यह काम करता है। मुझे याद है कि मूल Spanner पेपर में भी यह था
      कुछ दुर्लभ सिस्टम monotonic oscillator seconds का इस्तेमाल करते हैं और पृथ्वी के घूर्णन वाले seconds को अनदेखा करते हैं, लेकिन अगर कभी इसे वास्तविक समय में बदलना पड़े, तो समय के साथ आपदा जमा होती जाती है, इसलिए आम तौर पर इसे अच्छा विचार नहीं माना जाता
    • leap second, leap day की तरह नियमित शेड्यूल पर नहीं जोड़ा जाता, बल्कि पृथ्वी के भौतिक मापों पर निर्भर करता है
      इसलिए जिन high-reliability सिस्टमों में व्यापक time management होता है, वे शायद ऐसे निर्णयों से बहुत ज़्यादा प्रभावित नहीं होंगे

  • अगर Temporal API हो, तो क्या browser या Node.js वगैरह उस समय के आसपास की calculations में समय को सही तरह से संभाल पाएँगे? या गणना बिगड़ने से बचाने के लिए update की ज़रूरत होगी?

    • Temporal API शायद leap seconds को अनदेखा करने वाले Unix/POSIX timestamps पर आधारित है। Unix time में एक दिन हमेशा 86400 “seconds” का होता है
      इसलिए database के बिना भी अतीत और भविष्य के UTC calendar calculations आसानी से किए जा सकते हैं, और fractional seconds को संभालना भी ज़रूरी नहीं होता। leap second को OS 1 सेकंड दोहराकर, छोड़कर, या leap second के पहले और बाद के किसी समय-अंतराल में सेकंड की लंबाई समायोजित करके संभालता है
      ज़्यादातर date-time APIs मूल रूप से business features के लिए calendar और wall-clock calculations को सपोर्ट करने के लिए डिज़ाइन की गई हैं। अगर वैज्ञानिक उद्देश्यों के लिए SI second चाहिए, तो आपको अलग API और features का उपयोग करना चाहिए जो hardware level तक उसका आवश्यक अर्थ देते हों और उसकी guarantee करते हों
      इसी तरह, अगर thread sleep जैसी software सुविधाओं के लिए timer चाहिए, तो monotonic clock जैसे dedicated interface का उपयोग करना चाहिए। leap second धीरे-धीरे समाप्त भी हो जाए, तब भी यह स्थिति बहुत नहीं बदलेगी। leap second adjustment हो या न हो, उदाहरण के लिए mutex algorithm का Unix timestamps पर निर्भर होना पहले भी गलत था और आगे भी गलत रहेगा

  • मेरी बात सुनो। भूमध्य रेखा पर jet engines लगा देते हैं और 180 डिग्री घुमाकर समय को बढ़ा या घटा लेते हैं। फिर उसे मेरे snooze button से जोड़ देते हैं

    • क्या Superman का पृथ्वी के चारों ओर बहुत तेज़ी से कई बार घूमना ज़्यादा आसान नहीं होगा? तब engine maintenance की चिंता भी नहीं करनी पड़ेगी
    • वास्तव में, अगर बहुत बड़ी मात्रा में पानी इधर-उधर किया जाए, तो मापने लायक असर पड़ सकता है। उदाहरण के लिए California Central Valley aquifer को खाली करने जैसा
    • समस्या यह है कि भविष्य का समाज उन इंजनों को interstellar spacecraft के लिए वापस ले जाएगा। इस समस्या पर Larry Niven की किताबों की शृंखला में चर्चा की गई थी
    • शायद हम सब एक साथ एक ही समय पर कूद जाएँ। आखिर ज़रूरत सिर्फ 1–2 सेकंड की ही तो है?
    • इतने समय तक leap second डालने की ज़रूरत नहीं पड़ी, इससे लगता है कि यह तरीका चल गया

  • वहाँ लिखा है, “UTC और TAI के बीच अंतर 1 जनवरी 2017 0:00 UTC से अगली सूचना तक UTC-TAI = -37s है”
    क्या इसका मतलब है कि atomic clock, sundial से 37 सेकंड पीछे है? और 2017 का उल्लेख क्यों किया गया है, यह भी समझ नहीं आ रहा

    • बात लगभग उलटी है
      UTC का एक दिन ठीक 86400 SI seconds के रूप में परिभाषित है। लेकिन वास्तविक mean solar day कुछ milliseconds लंबा होता है। पृथ्वी के घूर्णन की अनियमितता के कारण यह अंतर स्थिर नहीं है, लेकिन औसतन यह समय के साथ धीरे-धीरे बढ़ने की उम्मीद है। SI second को atomic clock से मापा जाता है, इसलिए UTC atomic clock के 86400 seconds पूरे होने पर दिन बदल देता है
      दूसरी ओर, solar clock mean sun के दोपहर तक पहुँचने पर दिन बदलता है, इसलिए वह UTC की तुलना में कुछ milliseconds बाद दिन बदलता है। वास्तविक सूर्य साल भर आकाश में अलग-अलग गति से चलता है, इसलिए mean sun का उपयोग करना पड़ता है
      इसे दूसरे तरीके से कहें, तो solar clock जिस हर अवधि को ठीक 86400 सेकंड कहता है, वह atomic clock के हिसाब से कुछ milliseconds लंबी होती है
      यह हर दिन जमा होता रहता है, और जब यह लगभग 1 सेकंड तक पहुँच जाता है, तो UTC में leap second डाला जाता है, जिससे उस दिन की लंबाई 86400 सेकंड नहीं बल्कि 86401 सेकंड हो जाती है। UTC सिर्फ atomic clock time गिनने के लिए नहीं है; बहुत-सी मानवीय गतिविधियाँ आकाश में सूर्य की स्थिति से जुड़ी होती हैं, इसलिए उसे सूर्य के साथ भी sync रहना पड़ता है
      इंसानों ने “सूर्य के साथ sync” को “mean sun से 1 सेकंड के भीतर” के रूप में परिभाषित किया है। यानी हम चाहते हैं कि UTC noon, prime meridian पर mean solar noon से 1 सेकंड के भीतर रहे
      इसलिए 37 सेकंड का मतलब यह है कि अगर leap seconds का इस्तेमाल न किया गया होता, तो mean solar noon, UTC noon से कितना पीछे रह गया होता। जब UTC noon होता, तब mean sun को आकाश में prime meridian पार करने में अभी 37 सेकंड बाकी होते
    • Wikipedia के अनुसार दिसंबर 2016 आख़िरी बार leap second जोड़े जाने का समय था: https://en.wikipedia.org/wiki/Leap_second
    • 2017 का उल्लेख इसलिए किया गया है क्योंकि offset आख़िरी बार उसी समय बदला था। इसलिए -37 सेकंड तब से लगातार मान्य है