ब्रिटिश कोलंबिया, टाइम ज़ोन्स, और Postgres

टाइमस्टैम्प्स को स्टोर करना: UTC बनाम स्थानीय समय

• “हमेशा UTC स्टोर करो” पर कड़ा मतभेद।
• एक पक्ष कहता है: स्रोत सत्य के रूप में सिर्फ UTC Unix timestamps स्टोर करें; भरोसेमंद लाइब्रेरीज़ से कन्वर्ट करें; टाइमज़ोन इतने जटिल हैं कि उन्हें मैन्युअली संभालना चाहिए नहीं।
• दूसरे तर्क देते हैं कि जब wall clock time महत्वपूर्ण हो (अपॉइंटमेंट्स, punch-ins, office hours), तो यह एक “common mistake” है। Local time UTC से स्वतंत्र रूप से मौजूद होता है और अक्सर उसे सीधे स्टोर करना चाहिए।
• कुछ लोग ज़ोर देते हैं कि UTC literal instants (लॉग्स, पहले ही घट चुके events) के लिए उपयुक्त है, न कि local clocks से जुड़े domain concepts के लिए।

भविष्य की घटनाएँ और timezone बदलाव (BC मामला)

• मुख्य मुद्दा: “2pm local time” के रूप में सेट की गई भविष्य की अपॉइंटमेंट, अगर कानून बदल जाएँ (जैसे British Columbia का permanent daylight time पर जाना), तो एक अलग UTC instant पर मैप हो सकती है।
• इससे “authoritative” reference चुनने की मजबूरी आती है:
  • event location पर local wall time, या
  • मूल रूप से compute किया गया UTC instant, या
  • multi-timezone meetings में किसी और participant का local time।
• कई commenters इस बात पर ज़ोर देते हैं कि future events का कोई भी representation स्वाभाविक रूप से provisional होता है; governments और borders बदल सकते हैं।

Schema और modeling strategies

• भविष्य की घटनाओं के लिए प्रस्तावित तरीके:
  • local date/time + IANA timezone (जैसे America/Vancouver), वैकल्पिक रूप से location भी।
  • अपॉइंटमेंट्स के लिए, local time हेतु DATE/TIME या TIMESTAMP-without-timezone का उपयोग करें; केवल presentation layer में convert करें।
  • queries/optimization के लिए एक अतिरिक्त UTC instant रखें, लेकिन स्पष्ट रूप से चिन्हित करें कि कौन-सा field authoritative है।
• past events के लिए: कई लोग UTC सुझाते हैं, और timezone केवल तब जब local wall time का semantic महत्व हो (जैसे time clocks, historical analysis)।
• कुछ लोग timezone offsets और/या tzdata version या insertion time स्टोर करने का सुझाव देते हैं ताकि rules या data बदलने पर intent reconstruct किया जा सके।

Libraries, tzdata, और complexity

• सर्वसम्मति: timezone logic को कभी reimplement न करें; tzdata-backed libraries पर भरोसा करें।
• हालांकि, tzdata खुद past और future दोनों timestamps के लिए अक्सर बदलती रहती है, और उसमें historical errors भी हो सकते हैं।
• उठाए गए विचार: ऐसे systems जो हर record के लिए tzdata versions track करें, या “उस समय हम क्या मानते थे” के लिए bitemporal-जैसी रणनीतियाँ अपनाएँ।

DST, नीति, और BC की प्रतिक्रिया

• बहुत से लोग सामान्य रूप से DST की आलोचना करते हैं और permanent time के पक्ष में हैं, लेकिन इस पर असहमत हैं कि permanent standard time ज़्यादा स्वस्थ है या daylight time।
• British Columbia का permanent daylight time अपनाने का निर्णय विवादास्पद है; कुछ residents को clock changes का अंत पसंद है, जबकि अन्य का तर्क है कि consultation भ्रामक थी और standard time बेहतर होता।