- time zone जटिल होते हैं, लेकिन कंप्यूटर को इन्हें implement करना पड़ता है, इसलिए उनकी विचित्रता एक सीमित दायरे में ही होती है.
Asia/Kathmanduका UTC से एक अजीब offset है.Africa/Casablancatime zone model में ठीक से फिट नहीं बैठता, इसलिए इसे hardcode किया गया है.America/Nuuk-01:00 से daylight saving time शुरू करता है.Africa/CairoऔरAmerica/Santiago24 बजे (0 बजे नहीं) daylight saving time शुरू करते हैं.Australia/Lord_Howeके daylight saving time नियम सबसे अजीब हैं.
PGXIIREAM: Pope Gregory XIII सब कुछ नियंत्रित करते हैं
- दुनिया के अधिकांश हिस्से Gregorian calendar पर आधारित time system का उपयोग करते हैं.
- Gregorian calendar साल भर सूर्य की स्थिति को स्थिर रखने में बहुत उपयोगी है.
- UTC Gregorian calendar का आधुनिक औपचारिक रूप है, और पूरी दुनिया इसी के आधार पर समय निर्धारित करती है.
leap second महत्वपूर्ण नहीं हैं
- पृथ्वी का rotation धीमा हो रहा है, इसलिए इसकी भरपाई के लिए leap second जोड़े जाते हैं.
- leap second को नज़रअंदाज़ किया जा सकता है क्योंकि programming languages 61 सेकंड को represent नहीं करतीं.
- cloud providers leap second के दौरान घड़ी को धीमा चलाकर इस समस्या को संभालते हैं.
अजीब time zones
Asia/Kathmandu का offset अजीब है
- नेपाल UTC से 5 घंटे 45 मिनट आगे है.
- कंप्यूटर IANA time zone database के ज़रिए यह जानकारी जान सकते हैं.
PDT या CET जैसी strings का कोई मतलब नहीं है
- time zone identifiers अस्पष्ट हो सकते हैं, और कई time zones एक ही identifier साझा करते हैं.
daylight saving time वाले time zones को कैसे represent किया जाता है?
- daylight saving time transition rules जटिल होते हैं, और कंप्यूटर इन्हीं के आधार पर local time की गणना करते हैं.
Africa/Casablanca और Asia/Gaza चाँद का पालन करते हैं, लेकिन time zones सूर्य का पालन करते हैं
- मोरक्को और गाज़ा Ramadan के अनुसार daylight saving time को समायोजित करते हैं, और इसे hardcode किया गया है.
America/Nuuk -1 बजे daylight saving time में स्विच करता है
- Greenland यूरोप के समान समय पर daylight saving time शुरू करता है, लेकिन local time में यह -1 बजे शुरू होता है.
America/Santiago और Africa/Cairo 24 बजे स्विच करते हैं
- ये time zones 24 बजे daylight saving time में स्विच करते हैं, जिसका मतलब है अगले दिन में जाना.
Australia/Lord_Howe में सबसे अजीब daylight saving transition है
- Lord Howe Island में 30 मिनट का daylight saving transition होता है.
GN⁺ का सार
- time zones जटिल हैं, लेकिन कंप्यूटर को इन्हें implement करना पड़ता है, इसलिए उनकी विचित्रता एक सीमित दायरे में ही होती है.
Australia/Lord_Howe30 मिनट के daylight saving transition के कारण सबसे अनोखा time zone है.- यह लेख time zones की जटिलता को समझने में उपयोगी है और programmers के लिए दिलचस्प हो सकता है.
- समान functionality वाले projects में
tzdbशामिल है.
1 टिप्पणियां
Hacker News की रायें
tz database का सबसे मज़ेदार हिस्सा यह है कि इसमें Big Bang के समय का अनुमान शामिल है, और इसे इस तरह बनाया गया है कि Big Bang से पहले होने वाले timezone transitions की गणना न की जाए
https://github.com/eggert/tz/commit/b22d459a367f4d01b10f6f6b... के commit message का आशय भी यही था कि “Big Bang से पहले के timestamps भौतिक रूप से संदिग्ध हैं, इसलिए उन्हें generate न करें”, और जल्द ही एक अलग commit में Big Bang से पहले के leap seconds पर भी रोक लगा दी गई
dateमें पुरानी तारीखों के अर्थ पर एक लंबा manual page हुआ करता थाउसमें लगभग 15वीं सदी के उदाहरणों के साथ ऐसी कहानियां थीं कि किसी राजा को कोई खास सप्ताह/महीना पसंद था, इसलिए उसने उसे दोहराने का आदेश दिया, या किसी दूसरे राजा को कोई खास सप्ताह नापसंद था, इसलिए उसने उसे calendar से हटा दिया। यह काफी आंखें खोलने वाली reading थी, लेकिन अब मिल नहीं रही
दूसरे शब्दों में, निष्कर्ष यह है कि “Big Bang से पहले के क्षण इस library के scope से बाहर हैं, इसलिए अगर कोई algorithm केवल Big Bang से पहले गलत values देता है, तो वह algorithm स्वीकार्य है और उसे सुधारने/बदलने की जरूरत नहीं है”
उस हिस्से में bugs के मुकाबले utility बहुत ज्यादा नहीं दिखती, और tzdb की ज्यादातर messy complexity
zicमें है। कभी-कभी लगता है कि बेहतर होता अगरzicकोई ऐसा output न होता जिस पर दूसरे लोग निर्भर कर सकेंअच्छा होगा अगर timezone theory के पुरानी पड़ने से पहले timezone खुद ही गायब हो जाएं
मेरे हिसाब से सबसे अजीब timezone Africa/Addis_Ababa है। असल में Ethiopia के स्थानीय लोग उस तरीके का पालन नहीं करते
वहां समय को 6 घंटे आगे खिसकाकर देखा जाता है: सुबह, यानी 6 AM पर AM cycle शुरू होती है, और सूर्यास्त, यानी 6 PM पर PM cycle शुरू होती है
https://en.wikipedia.org/wiki/Time_in_Ethiopia
इसी तरह दिन 6 PM पर, thenashara पर खत्म होता है। सहज रूप से देखें तो यह English-speaking clock से कहीं ज्यादा समझ में आता है, और भाषा में ही रचा-बसा होने से समय को लेकर confusion भी कम होता है
https://en.wikipedia.org/wiki/Ethiopian_calendar
Ethiopian calendar में 30 दिनों के 12 महीने होते हैं, और 13वां महीना बनाने वाले 5 या 6 intercalary दिन होते हैं
https://en.wikipedia.org/wiki/Roman_timekeeping
English-speaking world में भी पहले 25 March को साल बदलता था: https://en.wikipedia.org/wiki/Calendar_(New_Style)_Act_1750#...
तकनीकी तौर पर दोनों ही ऐसी चीजें नहीं हैं जिन्हें tzdb handle कर सकता है। tzdb civil time को handle करता है, calendars या अन्य calculation methods को नहीं
Asia/Jerusalemकी अजीबियत इसलिए है क्योंकि daylight saving time church-state separation के मुद्दे से गहराई से जुड़ा है। धार्मिक लोग चाहते हैं कि सूर्यास्त पर शुरू होने वाले त्योहारों के हिसाब से workday सुविधाजनक रहेइसलिए 2000s के मध्य तक दशकों तक daylight saving time धार्मिक दलों और secular दलों के बीच हर साल होने वाली negotiation का नतीजा था, और transition dates अक्सर transition से ठीक पहले तय होती थीं, जिससे बार-बार समस्याएं आती थीं
अब भी Rosh HaShanah पर daylight saving time खत्म न हो, इसके लिए exception शामिल है, इसलिए future rules जटिल दिखते हैं
अगर EU अंततः इसे खत्म करने में सफल हो जाता है, तो शायद वे भी follow कर सकते हैं
इसलिए लोग नहीं चाहते कि daylight saving time पहले से ही देर से खत्म होने वाले event को और देर कर दे। साथ ही Yom Kippur के fast day पर वे चाहते थे कि fast 1 घंटा पहले खत्म हो। इन dates से match कराने की कोशिश में daylight saving time की अवधि बहुत छोटी हो जाती थी, इसलिए negotiation जरूरी हो गई
“Programming languages 61 सेकंड वाले minute को व्यक्त नहीं कर सकतीं” यह बात सच नहीं है। किसी ने पहले ही कहा था कि Raku leap seconds को support करता है, और यह शायद आंशिक रूप से मेरी वजह से हो सकता है
क्योंकि Perl 5 की सबसे लोकप्रिय date/time library
DateTime.pmleap seconds को support करती है, औरDateTime.pmबनाते समय मैंने ही वह support implement किया थापीछे मुड़कर देखें तो यह लगभग निश्चित रूप से गलती थी। leap seconds में रुचि रखने वाले लोग बहुत कम हैं, और यह बस “60 सेकंड जोड़ना 1 minute जोड़ने जैसा कभी-कभी क्यों नहीं होता?” जैसी अजीब उलझनें पैदा करता है
खासकर क्योंकि मैंने validate करने की कोशिश की कि
second => 60valid है या नहीं, code बहुत ज्यादा जटिल हो गया। constructor time components और arbitrary timezone लेता है, इसलिए leap second table check करने के लिए UTC में convert करना पड़ता है, लेकिन वह conversion खुद ऐतिहासिक कारणों से leap seconds वाले values से उलझ जाता हैबहुत छोटे फायदे के लिए यह एक बड़ी अव्यवस्था बन गई, और Raku की standard date/time library भी Perl 5 के
DateTime.pmसे काफी कुछ उधार लेती लगती है, इसलिए मुझे लगता है कि उसने भी उसी खराब design decision का कुछ हिस्सा inherit कर लियाशुरू में सोचने की प्रक्रिया क्या रही होगी, यह जानने की उत्सुकता है। क्या समस्या में बहुत ज्यादा डूब गए थे? जब आप किसी समस्या के बहुत करीब होते हैं और लंबे समय तक उस पर focus करते हैं, तो टूटने से पहले ही उसे ठीक करने का मजा कभी-कभी ऐसी चीजें करवा देता है
इसे कुछ इस तरह define किया गया है कि “Instant एक specific moment है जिसे atomic seconds और उनके fractional part में measure किया जाता है, और वह किसी epoch से बंधा या aware नहीं होता”
इस साल की शुरुआत में मुझे एक function लिखना पड़ा जो US address दिए जाने पर मौजूदा local time ढूंढे। naive तरीका state को statically timezone से map करना है, लेकिन ऐसे कई exceptions हैं जिनकी वजह से ऐसा नहीं किया जा सकता
उस application में cost और speed महत्वपूर्ण थे, इसलिए मैंने कुछ dollars में एक CSV खरीदी जिसमें सभी US ZIP code को UTC offset, daylight saving time follow करने या न करने आदि से map किया गया था
pytzIANA timezone name लेता है, इसलिए अंत में offset और daylight saving time जानकारी को manually किसी specific timezone से map करना पड़ा, और US overseas territories और military bases की वजह सेEtctimezone जैसी अजीब semantics भी चाहिए थीं[1] https://en.wikipedia.org/wiki/Tz_database#Area
ZIP code भी शायद पर्याप्त हो सकता है, लेकिन सावधानी रखनी होगी। अगर addresses की संख्या बहुत ज्यादा नहीं है, तो ज्यादा robust तरीका है reverse geocoding करना और फिर timezone boundary shapes से IANA identifier पाने वाली library इस्तेमाल करना
https://github.com/RomanIakovlev/timeshape को मेरे एक पुराने colleague maintain करते हैं, और हम अपने internal काम का कुछ हिस्सा open source कर पाए थे
एक-दो systems data को local time में timestamp करते थे और बाकी UTC इस्तेमाल करते थे। daylight saving time handle करने के लिए algorithm बनाने की कोशिश में मैंने पुराना Farmers' Almanac खरीदा, लेकिन rules पढ़कर निराश हो गया
calendar में transitions के nominal rules थे, लेकिन footnote में लिखा था कि Congress की intervention के कारण उन्हें हर साल adjust किया जाता रहा है और आगे भी किया जाएगा। मैंने अपने boss से कहा, “अगर मैं Congress के future votes predict करने वाला algorithm लिख सकता, तो मैं billionaire बनकर यह engineering job छोड़ चुका होता”
आखिरकार शायद मैंने हाल के known transitions और future के nominal rules code किए। वह समय था जब हर कोई network से connected नहीं था, और code VAX जैसे standalone computers पर चलता था, इसलिए ज्यादा विकल्प नहीं थे
तीन tracking data sources को merge करना भी nightmare था, जिनमें हर एक की अपनी validity और measurement quality degradation state थी, लेकिन फिर भी वह Congress के future actions predict करने से आसान था
US/Easternजैसे named timezone से map करना है। उसके बाद अगर UTC offset चाहिए, तोpytzसे उस date पर timezone apply करके offset मिल जाता हैnamed timezone खास होते हैं क्योंकि वे fixed रहते हैं।
-05:00जैसे UTC offset timezones याESTजैसे abbreviations daylight saving time की वजह से किसी specific location पर time के साथ fixed नहीं रहतेअगर आप किसी से timezone पूछते समय offset या abbreviation को options के रूप में देते हैं, तो सभी confuse हो जाते हैं
latitude/longitude → timezone conversion के लिए यह Python library इस्तेमाल की: https://github.com/jannikmi/timezonefinder
data source भी काफी high-quality source जैसा लगा: https://github.com/evansiroky/timezone-boundary-builder/rele...
Etcidentifiers के साथ सचमुच सावधान रहना चाहिए। खासकर अगर आप सभी identifiers को जस का तस users के सामने expose करना चाहते थेउस file में comment है: “POSIX Greenwich के west को positive रखता है, लेकिन बहुत से लोग Greenwich के east को positive मानते हैं। उदाहरण के लिए
TZ='Etc/GMT+4'abbreviation-04इस्तेमाल करता है और UT से 4 घंटे पीछे, यानी Greenwich के west को दर्शाता है, लेकिन बहुत से लोग इसे UT से 4 घंटे आगे east मानते हैं”फिलिस्तीन का time zone भी काफ़ी अजीब है
https://en.wikipedia.org/wiki/Time_in_the_State_of_Palestine
वहाँ daylight saving time है, लेकिन तारीखें fixed नहीं होतीं; सरकार हर साल शुरुआत और समाप्ति का समय घोषित करती है। कभी-कभी एक हफ्ते से भी कम समय पहले घोषणा होती है, इसलिए तरह-तरह की दिलचस्प समस्याएँ पैदा होना तय है
इज़राइल और फिलिस्तीन में daylight saving time की शुरुआत और समाप्ति की तारीखें ज़रूरी नहीं कि एक जैसी हों
1 घंटे के बजाय 30 मिनट के अंतर वाले daylight saving time को “सबसे अजीब time zone” कहना मुझे बहुत कम bar लगता है
लगभग बाकी चीज़ें ज़्यादा अजीब हैं। Antarctica/Troll निश्चित रूप से ज़्यादा अजीब लगता है, और मोरक्को व गाज़ा के time zones में कम से कम अलग तरह के नियम हैं, क्योंकि उन्हें मौजूदा system से express नहीं किया जा सकता। Apple की ban list में आए, किसी खास तारीख से एक दिन पहले switch होने वाले time zones भी इतने अजीब हैं कि कुछ न कुछ तोड़ सकते हैं
leap second के बारे में सहमत हूँ। यह programmers को जानने लायक उपयोगी ज्ञान से ज़्यादा लगभग trivia है। computers leap seconds को smear कर देते हैं, और उन्हें यह भी नहीं पता होता कि वे कब हुए। इसे पूरी तरह भूलकर भी रहा जा सकता है
हालांकि देशों ने कभी leap seconds को ignore करने के तरीके से उन्हें consider करने के तरीके की ओर transition किया था, इसलिए कुछ दशकों पहले ऑस्ट्रेलिया में
GMT+xसेUTC+xमें बदलाव, leap seconds को ignore करने से उन्हें शामिल करने की ओर transition था। यह बात लगभग सार्वभौमिक रूप से ignore की जाती है, शायद यह बेहतर ही हैलेकिन जब कोई बड़ा संगठन कहता है कि “हमारे servers में GPS synchronization और हमारे खुद बनाए PCIe rubidium atomic clock card की वजह से sub-millisecond time accuracy है”, और साथ ही कहता है कि “leap seconds को एक दिन में smear किया जाता है, इसलिए असल में server time ±0.5 second गलत हो तो भी फर्क नहीं पड़ता”, तो यह हमेशा थोड़ा मज़ेदार लगता है
[1] https://engineering.fb.com/2021/08/11/open-source/time-appli...
[2] https://engineering.fb.com/2020/03/18/production-engineering...
उदाहरण के लिए, अगर आसमान बहुत बादलों से ढका हो, तो चाँद जहाँ भी हो, दिखाई नहीं देगा। इसी वजह से किसी देश के संचालन में calendar implement करते समय समस्या आती है
इस्लामी calendar को आधिकारिक रूप से अपनाने वाले कई देश किसी खास location पर expected visibility के आधार पर पहले से calculated approximate dates का उपयोग करते हैं। इसलिए इस्लामी calendar असल में एक नहीं, बल्कि observation-based Islamic calendar और predicted calendar—इन दो के करीब है, और दोनों ही उस location पर निर्भर करते हैं जहाँ actual या predicted observation किया जाता है
मोरक्को या गाज़ा इसे कैसे करते हैं, पता नहीं
बस Norway time में संयोग से daylight saving time का उपयोग होता है
कई markets leap second के दौरान बंद रहे, और कई banks error risk कम करने के लिए local time change के समय अब भी सभी transactions रोक देते हैं
जिन applications को इसकी बहुत परवाह नहीं होती, उनमें भी leap second से जुड़े bugs हैरानीजनक रूप से ज़्यादा रहे हैं, और CGPM ने leap seconds को खत्म करने का फैसला अच्छे कारणों से किया है
https://en.wikipedia.org/wiki/Leap_second#Other_reported_sof...
टाइमज़ोन सॉफ़्टवेयर की कलाबाज़ियों पर एक शानदार लेख है। सच में काफ़ी flexible है
अगर सब कुछ automated finite offsets ही हैं, तो daylight saving policy को ज़रूरी नहीं कि 60 मिनट के adjustment तक सीमित रहना पड़े
क्या कोई देश पूरे साल लगातार बदलते offset का इस्तेमाल करने का फ़ैसला कर सकता है? offset lookup table काफ़ी लंबी हो जाएगी, लेकिन इससे daylight saving time को “हल” भी किया जा सकता है। लगातार थोड़े-थोड़े adjustment होते रहेंगे, इसलिए leap second की तरह शायद पता भी नहीं चलेगा
analog clock पर निर्भर लोग शायद अब हर बार एक ही दिशा में adjustment न करें
महीने में एक बार 10 मिनट का बदलाव अपनाना कहीं आसान है, लगभग पता भी नहीं चलेगा, और अगर छूट भी जाए तो 1 घंटे की गलती जितनी बड़ी समस्या नहीं होगी
daylight saving time बंद कर दीजिए। निजी तौर पर मैं permanent daylight saving time की बजाय permanent standard time पसंद करूँगा, लेकिन अगर साल में दो बार घड़ी बदलना बंद हो जाए तो मुझे मंज़ूर होगा
बेशक China तो मशहूर तौर पर इतना बड़ा है फिर भी उसके पास सिर्फ़ एक time zone है, जिससे अंदरूनी और बाहरी दोनों तरह से दिलचस्प स्थितियाँ बनती हैं
TZif data format में साफ़ तौर पर न दिखने वाली एक बहुत महत्वपूर्ण assumption यह है कि local time से UTC time में जाते समय possibilities अधिकतम दो ही होती हैं
बहुत-सा software इसी assumption पर निर्भर है, उदाहरण के लिए
java.time.LocalDateTimeमेंwithLaterOffsetAtOverlap()है: https://docs.oracle.com/javase/8/docs/api/?java/time/LocalDa...यह implicitly मानता है कि जब सुबह 2:30 का मतलब ambiguous हो, तो संभावित solutions सिर्फ़ daylight saving time से पहले और बाद वाले दो ही होंगे। अगर कोई time zone सुबह 2 बजे एक बार पीछे जाए और 2:15 पर फिर पीछे जाए, इस तरह तीन या उससे अधिक solutions बना दे, तो बहुत-सी चीज़ें इसे represent नहीं कर पाएँगी
tz database में मुझे जो बात पसंद है वह यह है कि तकनीकी रूप से यह diff का diff है
यह store करता है कि हर time zone और UTC के बीच का अंतर इतिहास में कैसे बदला, इसलिए इसे
diff^2कहा जा सकता है। लेकिन tz database को updates भी मिलते हैं, इसलिए वे commits diff के diff का diff, यानीdiff^3हैंऔर आगे जा सकते हैं। changelog है और वह changelog git में store है, इसलिए tz changelog पर commit, UTC के मुकाबले changes की list की changes की list की changes की list पर change है, यानी
diff^4मुझे लगता है मुख्य framing यह है कि लगभग हर date/time असल में निगरानी में रखे गए matching rules का set है
matching trigger होने में कितने seconds लगेंगे, इसका अनुमान लगाया जा सकता है, लेकिन जब तक वह सच में न हो जाए तब तक पूरी तरह यक़ीन नहीं हो सकता, और कुछ मामलों में वह बिल्कुल ठीक-ठीक कभी हो ही नहीं सकता
उसके बाद दूसरा आधा काम है “शायद अभी से X seconds बाद होगा” वाले delta estimate को वापस “उस समय आपके time zone की घड़ी शायद Y दिखाएगी” में बदलना
यह track करते रहना नहीं भूलना चाहिए कि कौन-सा time zone event को control कर रहा है, और वह किस time zone में display हो रहा है
[1] UTC estimate leap seconds जितना आगे-पीछे चूक सकता है। TAI ज़्यादा सुरक्षित है, लेकिन अगर कोई cesium atoms के व्यवहार को बदलने वाली कोई दिलचस्प और नई चीज़ खोज ले, तो बात बदल सकती है
[0] उदाहरण के लिए कोई देश खत्म हो जाए और time zone गायब हो जाए। या घड़ी 1:00 से 2:00 पर jump कर जाए, जिससे छूटे हुए 1 घंटे के कारण 1:30~2:00 का interval ठीक-ठीक कभी घटित ही न हो