किसी ऐप को दूसरे टाइम ज़ोन में चलाएँ

ग़लत दिन पर पड़ने वाली रिपोर्ट, एक घंटा पहले बजने वाला रिमाइंडर, कल जैसा पढ़ा जाने वाला टाइमस्टैम्प - इनमें से ज़्यादातर सिर्फ़ उस ज़ोन में दिखते हैं जिसमें आप नहीं बैठे। यह एक प्रोसेस को उसका अपना ऑफ़सेट देता है, जबकि आपका सिस्टम ज़ोन ठीक वहीं रहता है जहाँ था।

आम जवाब मदद क्यों नहीं करते

Windows का टाइम ज़ोन बदलना उसे हर चीज़ के लिए बदल देता है - आपका कैलेंडर, आपके लॉग, आपकी मीटिंग - और किसी प्रबंधित मशीन पर उसे बदलना शायद आपके हाथ में न हो।
TZ सेट करना कुछ रनटाइम के लिए चलता है और कुछ के लिए नहीं। GetTimeZoneInformation पढ़ने वाला नेटिव Windows ऐप्लिकेशन उसे बिल्कुल महसूस नहीं करेगा।
ब्राउज़र डेवलपर टूल किसी वेब पेज का ज़ोन ओवरराइड करते हैं, जो बढ़िया है, और डेस्कटॉप ऐप्लिकेशन के लिए अप्रासंगिक।

एक प्रोसेस, एक ऑफ़सेट

सत्र का अपना ऑफ़सेट होता है। ऐप्लिकेशन Windows से पूछता है कि वह किस ज़ोन में है और उसे वही जवाब मिलता है, जबकि मशीन का हर दूसरा प्रोग्राम असली जवाब पाता है।

# वही क्षण, अमेरिकी पश्चिमी तट से देखा गया
chrono run "C:\apps\test.exe" --at 2027-01-15T09:00:00 --zone -08:00

# केवल ज़ोन - आज की असली तारीख़, किसी और की घड़ी
chrono run "C:\apps\test.exe" --zone +09:00

कैलकुलेटर सवाल के दूसरे आधे हिस्से का जवाब देता है - कोई दिया हुआ क्षण कहीं और असल में क्या पढ़ा जाता है। बदलने पर क्षण वही रहता है और केवल दीवार की घड़ी बदलती है, और तारीख़ ग़लत दिन पर ठीक इसी तरह पड़ती है:

$ chrono calc --base 2027-01-15T09:00:00 --zone +01:00 --to-zone -08:00
Chrono Mock - date calculator
  base:    2027-01-15T09:00:00
  step 1:  zone -08:00  -> 2027-01-15T00:00:00
  result:  2027-01-15T00:00:00
  formats:
    ISO date      2027-01-15
    ISO datetime  2027-01-15T00:00:00-08:00
    US            01/15/2027
    PL            15.01.2027

मध्य यूरोप में सुबह के नौ बजे अमेरिकी पश्चिमी तट पर आधी रात होती है। वही क्षण, और स्थानीय तारीख़ से समूह बनाने वाली दैनिक रिपोर्ट उसे इस पर निर्भर करके अलग दिन में डालती है कि वह कहाँ चल रही है।

ईमानदार सीमाएँ, और यहाँ वे मायने रखती हैं

सत्र का ज़ोन डेलाइट सेविंग के बिना एक स्थिर ऑफ़सेट है।

+01:00 पर सेट सत्र +01:00 पर ही रहता है, चाहे उसकी घड़ी जनवरी पढ़े या जुलाई। इसलिए असली बदलाव को पार करने वाला रन उस घंटे से भटक जाता है जो वह ज़ोन वास्तव में दिखाता, और किसी ऐप्लिकेशन को डेलाइट सेविंग के बदलाव से गुज़ारना अभी वह चीज़ नहीं है जो यह टूल करता है। तारीख़ कैलकुलेटर अंदाज़ा लगाने की जगह यही बताता है।

ज़ोन अपने को “Chrono Session” बताता है, ऐसा नाम जिसे कोई Windows रजिस्ट्री नहीं जानती। जो भी उस नाम को वापस किसी ज़ोन से जोड़ता है - .NET का TimeZoneInfo.Local उनमें से है - वह इसकी जगह ऑफ़सेट पर लौट आता है, जो सही जवाब है। जो ऐप्लिकेशन रजिस्ट्री का नाम ही माँगता है उसे वह नहीं मिलेगा।
Java सत्र के ज़ोन को ऑफ़सेट के रूप में लेता है। सत्र के ज़ोन में न डेलाइट सेविंग है न उसके पीछे कोई शहर, इसलिए Java उसे उसके ऑफ़सेट पर नाम देता है - +05:30 के सत्र के लिए GMT+05:30।
Chromium और Electron मोड में पेज भी सत्र का ज़ोन पढ़ते हैं। यह वही स्थिर ऑफ़सेट है: हर पेज और हर worker को उस पर रखा जाता है और वह जो पढ़ता है उसकी जाँच करता है। Electron ऐप्लिकेशन की मुख्य प्रक्रिया Node में JavaScript चलाती है, जहाँ सत्र नहीं पहुँचता, इसलिए वह असली घड़ी पर रहती है।
ऑफ़सेट -14:00 से +14:00 तक पूरे मिनटों में चलते हैं। इसके बाहर की कोई भी चीज़ चुपचाप लपेटी जाने की जगह अस्वीकार कर दी जाती है।

इनमें से कौन-सी आपके ऐप्लिकेशन पर लागू होती है, यह अंदाज़े की जगह नापने की बात है। सत्र अपनी कवरेज ख़ुद रिपोर्ट करता है →

आज़माएँ

Windows के लिए डाउनलोड करें FAQ पढ़ें