आप जिस भी तरीके से इसे करते हैं, जो बदल रहा है उसके आधार पर यह अलग-अलग तरीकों से विफल होगा।
-
अगर आप टाइमस्टैम्प को टाइमज़ोन के अनुसार
2013-12-29 12:34:56 America/New_Yorkके रूप में स्टोर करते हैं , यह विफल हो जाएगा यदि, कहते हैं, ब्रोंक्स अचानक अपना टाइमज़ोनAmerica/New_York_Bronxशुरू कर देता है एक अलग ऑफ़सेट के साथ और आपका ईवेंट ब्रोंक्स में हुआ।तय करें कि इसकी कितनी संभावना है और विफलता कितनी बुरी होगी।
-
यदि आप यूटीसी में टाइमस्टैम्प स्टोर करते हैं और जिस समय क्षेत्र में घटना हो रही है, वह उनके ऑफसेट को फिर से परिभाषित कर रहा है (उदाहरण के लिए डीएसटी तिथियों को चारों ओर स्थानांतरित करना, या पूरी तरह से एक अलग ऑफसेट पर स्थानांतरित करना), घटना का समय उस स्थान पर वास्तविक दीवार घड़ी के समय से भिन्न हो सकता है। अगर आप
2013-12-29 12:34:56 UTCstore स्टोर करते हैं बर्लिन, जर्मनी और बर्लिन में 13:34:56 पर एक कार्यक्रम के लिए अपने DST को इधर-उधर शिफ्ट करते हैं,2013-12-29 12:34:56 UTCअब स्थानीय समयानुसार 14:34:56 बर्लिन के अनुरूप हो सकता है, जबकि घटना अभी भी स्थानीय समयानुसार 13:34 बजे हो रही है।तय करें कि इसकी कितनी संभावना है और विफलता कितनी बुरी होगी।
-
यदि आप यूटीसी टाइमस्टैम्प को स्टोर करते हैं और इसे किसी भौतिक स्थान से लिंक करते हैं जिसे आप टाइमज़ोन से लिंक करते हैं, तो आप दोनों समस्याओं का सामना कर सकते हैं। लेकिन इसके लिए आपको केवल "न्यूयॉर्क" ही नहीं, बल्कि सटीक भौतिक स्थान को संग्रहित करना होगा, अन्यथा आपके पास केवल केस 1 होगा, एक और मध्यवर्ती चरण के साथ। यदि आप सटीक भौतिक स्थान संग्रहीत करते हैं और इस स्थान को एक समय क्षेत्र में हल करने का एक सटीक तरीका है और आप अपना समय क्षेत्र डेटाबेस अद्यतित रखते हैं, तो आप सभी परिवर्तन परिदृश्यों को काफी हद तक संभाल सकते हैं।
तय करें कि यह कितना व्यावहारिक है और यह अतिरिक्त सटीकता आपके लिए कितनी उपयोगी है।
