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

 (aphyr.com)
2 पॉइंट द्वारा GN⁺ 2024-12-27 | 1 टिप्पणियां | WhatsApp पर शेयर करें

  • Epoch के बाद के सेकंड

    • POSIX time, या Unix time, को आम तौर पर 1 जनवरी 1970 00:00:00 के बाद के सेकंड्स के रूप में जाना जाता है। लेकिन यह सटीक नहीं है। उदाहरण के लिए, 25 दिसंबर 2024 18:54:53 UTC का POSIX time 1735152686 है, जो वास्तव में बीते 1735152715 सेकंड्स से 29 सेकंड कम है.

    • POSIX time, IEEE 1003.1 में Coordinated Universal Time (UTC) से व्युत्पन्न है। यह मानक मानता है कि हर दिन ठीक 86,400 सेकंड का होता है। लेकिन वास्तव में एक दिन की लंबाई 86,400 सेकंड नहीं होती, और समय के साथ बदलती रहती है। इसे समायोजित करने के लिए खगोलशास्त्री समय-समय पर UTC में leap second घोषित करते हैं.

  • पुरातत्व

    • IEEE 1003 के Appendix B में leap second पर एक रोचक चर्चा शामिल है। मानक के प्रकाशित होने तक, 1 जनवरी 1970 के बाद 14 leap second जोड़े जा चुके थे। समय-अंतर की गणना आसान बनाने के लिए इन leap seconds को अनदेखा किया गया.

    • अधिकांश सिस्टम समय को लगातार बढ़ने वाले मान के रूप में मानते हैं। लेकिन अधिकांश सिस्टम leap second को ट्रैक नहीं करते और न ही standard time reference के साथ synchronized होते हैं। इसलिए यह अपेक्षा करना उचित नहीं है कि epoch के बाद के सेकंड संदर्भित समय और epoch के बीच के सेकंड्स को ठीक-ठीक दर्शाएँ.

    • epoch के बाद के सेकंड्स की एकसमान व्याख्या कुछ प्रकार के distributed applications के लिए महत्वपूर्ण हो सकती है। leap seconds का संचय पूर्वानुमानित नहीं है, और epoch के बाद leap seconds की संख्या बढ़ने की संभावना है.

  • इसके बजाय क्या करें

    • एक ही कंप्यूटर पर दो events के बीच duration निकालने के लिए CLOCK_MONOTONIC का उपयोग करना चाहिए। अगर दूसरे सिस्टम्स के साथ POSIX time का आदान-प्रदान आवश्यक नहीं है, तो TAI, GPS, या LORAN का उपयोग किया जा सकता है.

    • अगर POSIX timestamp system के साथ मोटे तौर पर alignment चाहिए, तो leap second को लंबे time window में फैलाया जा सकता है। qntm की t-a-i जैसी libraries POSIX और TAI के बीच conversion को support करती हैं.

    • leap second को समाप्त करने के प्रयास जारी हैं, और आशा है कि यह 2035 तक पूरा हो जाएगा। इससे उन सभी चीज़ों के लिए conversion tables बनाने का अतिरिक्त काम होगा जो "एक दिन में 86,400 सेकंड" की धारणा का उपयोग करती हैं, लेकिन दो समयों के बीच सेकंड पूछना अधिक सरल हो जाएगा। कम-से-कम 2035 के बाद के समय के लिए.

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

1 टिप्पणियां

 
GN⁺ 2024-12-27
Hacker News राय

  • मैंने "A Deepness in the Sky" नाम की एक SF किताब पढ़ी। किताब में epoch के बाद के seconds का ज़िक्र दिलचस्प लगा

    • Qeng Ho की time measurement method जटिल थी, और seconds की गिनती उस पल से शुरू होती थी जब इंसानों ने पहली बार चाँद पर कदम रखा
    • शुरुआत का क्षण वास्तव में लगभग 1.5 करोड़ seconds बाद था, और यही शुरुआती computer operating system का 0 second था

  • leap second को खत्म करने की कोशिश चल रही है, और उम्मीद है कि 2035 तक यह पूरा हो जाएगा

    • UTC का उद्देश्य TAI से integer seconds जितना अलग रहकर mean solar time का approximation देना है
    • अगर MST को track नहीं करना है, तो TAI पर switch करना चाहिए, और अगर UTC, MST से अलग हो जाता है तो ऐतिहासिक leap seconds का मतलब नहीं रह जाता

  • आधुनिक "UTC epoch" 1 जनवरी 1972 है

    • 1971 के अंत में 0.107758 TAI seconds का एक irregular jump था, और उसके बाद UTC की tick rate को इस तरह बदला गया कि वह TAI से बिल्कुल match करे
    • 1970 और 1971 का Unix time वास्तव में उस अवधि के UTC time से मेल नहीं खाता

  • जब भी time measurement के बारे में पढ़ता हूँ, कुछ नया सीखता हूँ

    • मुझे लगा था कि Unix time time tracking का सबसे सरल तरीका है
    • मैंने सोचा था कि leap seconds लागू नहीं होते, लेकिन शायद मैंने इस पर पर्याप्त सोचा नहीं था

  • हाल ही में VAX, या OpenVMS पर चलने वाले code पर काम किया, और पहली बार देखा कि उसका epoch 17 नवंबर 1858 है

    • code में इसे Unix epoch के रूप में abstract किया गया था

  • कुछ time points को POSIX timestamp के रूप में व्यक्त नहीं किया जा सकता, और कुछ POSIX timestamps वास्तविक समय से मेल नहीं खाते

  • मुझे लगता है इस article ने Christmas खराब कर दिया

    • seconds, epoch के बाद के seconds होने चाहिए, और solar day से drift होने में कोई समस्या नहीं होनी चाहिए
    • second-epoch converter को correction का काम संभालना चाहिए

  • database में dates store करते समय मैं हमेशा Unix epoch time में store करता हूँ, और timezone information अलग से store करता हूँ

    • मैं सोच रहा हूँ कि क्या TAI format में timestamps store करना और ज़रूरत पड़ने पर UTC में convert करना बेहतर होगा
    • timezone इंसानों द्वारा बनाई गई अवधारणा है, और समय के साथ इसमें बदलाव होते रहते हैं
    • absolute time को आधार बनाना चाहिए, और ज़रूरत पड़ने पर उसे local time format में convert करना चाहिए

  • लगभग 10 साल पहले एक conference में सुना था कि Google leap seconds का उपयोग नहीं करता, बल्कि उन्हें सामान्य seconds में फैला देता है

    • Google ने अपने NTP servers को modify करके leap second को distribute किया

  • मैं सोच रहा हूँ कि क्या time measurement का कोई ऐसा तरीका है जो synchronized भी हो और monotonically increasing भी