क्या यूटीसी में समय स्टोर करने का कोई अच्छा कारण नहीं है?

मुझे आश्चर्य है कि क्या यूटीसी (जीएमटी) के किसी भी अन्य समय में समय की जानकारी स्टोर करने के कोई अच्छे कारण हैं? मेरा मानना है कि यह सभी सॉफ्टवेयर इंजीनियरिंग के लिए एक ठोस नियम है। स्थानीय समय में रूपांतरण केवल एक अनुवाद है जो यूआई परत पर प्रदर्शन उद्देश्यों के लिए होता है। मैंने उन मामलों को भी देखा है जहां एक एल्गोरिदम सही ढंग से कार्यान्वित करने के लिए अनुवाद की आवश्यकता है (मध्यरात्रि दिनांक परिवर्तनों को संभालने के लिए, आदि)।क्या यूटीसी में समय स्टोर करने का कोई अच्छा कारण नहीं है?

स्रोत

2009-07-14 Landon Kuhn

आप कुछ वास्तविक दुनिया की घटनाओं का प्रबंधन करने के लिए एक सर्वर डिज़ाइन कर रहे हैं कहो। कहें कि "लॉस एंजिल्स में, हर मंगलवार को 2 पीएम से 3 पीएम तक" एक घटना होती है। यूटीसी में आप इसे कैसे स्टोर करते हैं? –

मैं कहूंगा कि यह एप्लिकेशन-निर्भर है। मैं आयनोस्फीयर & मैग्नेटोस्फीयर के अंतरिक्ष भौतिकी मॉडल पर काम करता हूं। हम चुंबकीय स्थानीय समय के साथ काम करते हैं, & दिनांक Modified Julian Days के रूप में संग्रहीत करते हैं।

स्रोत

2009-07-14 20:25:24 Pete

जब आप सुनिश्चित हैं कि केवल स्थानीय समय का उपयोग किया जा रहा है।

स्रोत

2009-07-14 20:26:39 FerranB

फिर भी, यूटीसी का उपयोग करने के लिए कोई अच्छा मामला है यदि किसी भी प्रकार की घड़ी की गतिविधि हो। अन्यथा, डेलाइट-बचत क्रॉसओवर को संभालना एक विशाल पिटा बन जाता है। मैं कड़वा अनुभव से बात करता हूँ। –

या यदि समय क्षेत्र बदला जा सकता है। स्थानीय समय को अपडेट करना होगा। –

अलार्म & निर्धारित कार्यों को कभी-कभी स्थानीय समय में संग्रहीत किया जाता है ताकि वे डेलाइट सेविंग टाइम या टाइमज़ोन परिवर्तन से प्रभावित न हों।

स्रोत

2009-07-14 20:28:30

क्या वे स्थानीय समय में/संग्रहीत/हैं या यूटीसी प्राप्त करने का एक बेहतर तरीका होगा और एक कन्वर्ट टोलोकलटाइम() सदस्य फ़ंक्शन होगा? – Pete

@Pete: मेरी अलार्म घड़ी के बारे में सोचें: अलार्म 7am स्थानीय समय पर सेट है। जब घड़ियां सर्दी में वापस जाती हैं, तो मैं 6 बजे उठना नहीं चाहता। जब मैं पश्चिम से बाहर एक व्यापार यात्रा पर जाता हूं, तो मैं रात के मध्य में जागने की इच्छा नहीं करता क्योंकि यह 7 बजे घर वापस है। – dave4420

@ डेव हाँ, तो आप बस TIME_ZONE + = n बदल देंगे, इसलिए कनवर्ट करें ToLocalTime (currentUtc, TIME_ZONE, isDaylightSavingsTime) स्थानीय समय लौटाएगा (भले ही यह आंतरिक रूप से यूटीसी के रूप में संग्रहीत हो)। – Pete

कभी? मुझे यकीन है कि कुछ अलग मामलों में अच्छे कारण हैं। सामान्य रूप से, हालांकि, स्थानीय समय की तुलना में यूटीसी भंडारण बहुत बेहतर है, इसलिए जब तक कुछ विशेष विचार न हो तो मैं यूटीसी को डिफ़ॉल्ट स्थिति के रूप में मानूंगा।

स्रोत

2009-07-14 20:39:31

आम तौर पर मुझे यूटीसी का उपयोग करना बेहतर लगता है। कभी-कभी आपको स्थानीय समय की आवश्यकता हो सकती है। फिर मैं यूटीसी + टाइमज़ोन जानकारी के साथ जाऊंगा।

सामान्य समय में दोहराव की घटनाओं के लिए बेहद मुश्किल हो सकता है, और आपको उपयोग मामलों का बहुत सावधानीपूर्वक विश्लेषण करना चाहिए।

प्रत्येक मंगलवार सुबह 9: 00 बजे एक आवर्ती बैठक की कल्पना करें। यदि डीएसटी बदलता है, तो बैठक अभी भी 9:00 बजे (नई) पर होनी चाहिए।

लेकिन फ्रांस में कुछ लोगों की बैठक में कोई जोड़ नहीं है। उनके लिए बैठक 6:00 बजे है। और वे डीएसटी को एक अलग नियम से बदलते हैं।

जब आप डीएसटी बदलते हैं, तो वे थोड़ी देर के लिए नहीं (जब तक फ्रांस डीएसटी नहीं बदलता) किसी को "बंद" होना चाहिए: या तो आपकी बैठक 10 बजे होगी कि उनका 6 बजे रहेगा, या आपका 9 बजे और 5 बजे उनका स्थानांतरित करें। कोई अन्य तरीका नहीं है, कंप्यूटर के पास इसके साथ कुछ लेना देना नहीं है।

एक आवेदन कैसे तय करेगा कि "तय" कौन होना चाहिए? क्या यह अधिकांश सदस्यों के साथ समूह है? (फ्रांस में यूएस बनाम 20 में 1 लड़का?) या यह व्यक्ति के महत्व के बारे में है? (क्या होगा यदि अमेरिका में 1 व्यक्ति सीईओ है?)

आप उस जानकारी को कैसे स्टोर करते हैं? मेरा सबसे अच्छा समाधान यूटीसी + एक "मास्टर टाइम जोन" "मास्टर टाइम जोन" जीतने वाले उपयोगकर्ताओं (निश्चित रहने के लिए) का उपयोग करना है।

चीजें बहुत मुश्किल हो सकती हैं, लेकिन आम तौर पर मुझे पता चला है कि यूटीसी ने इसकी तुलना में अधिक संभावनाएं हल की हैं।

स्रोत

2009-07-15 09:40:19

+1 ग्रेट उदाहरण केस – Triptych

अगर मैं गलत हूं तो कृपया मुझे सही करें, लेकिन मुझे लगता है कि यूटीसी + मास्टर टाइम जोन संग्रहीत करना डीएसटी परिवर्तन की इस समस्या को हल नहीं करता है। व्यावहारिक उदाहरण: 1 - आपको 9:00 एनवाई समय में "1 साल से डेटाटाइम" स्टोर करने की आवश्यकता है। यदि आप यूटीसी में यह गणना करते हैं और एनवाई समय क्षेत्र के साथ इसे अपने डीबी पर स्टोर करते हैं। 2 - 1 साल बीतने से पहले, NY ने इसे डीएसटी बदल दिया। 9 बजे एनवाई समय पर वह मूल तारीख उसी तारीख तक नहीं है जिसे हमने संग्रहित किया है। – fjsj

एक एम्बेडेड सिस्टम में आप अच्छी तरह से किसी प्रकार का में एक स्रोत से समय प्राप्त हो सकती है "टिक्स अतीत युग" फ़ॉर्म।

तो समय अपेक्षाकृत अपडेट किया जाता है, और अपेक्षाकृत कम है, तो आप इसे भी उसी तरह यह आप पर आपूर्ति की है में संग्रहीत कर सकता है और केवल प्रदर्शन के लिए परिवर्तित जब जरूरत का प्रदर्शन किया।

सामान्य रूप से, हालांकि, यूटीसी तब तक जाने का तरीका है जब तक अन्य विचार न हों।

स्रोत

2009-07-15 09:48:03 Vicky

UTC एक समय कीपिंग मानक सटीकता और TAI की शुद्धता है कि है, लेकिन अनियमित अंतराल पर में जोड़ा छलांग सेकंड के साथ इसे बारीकी से मतलब सौर समय (UT1) ट्रैक करने के लिए अनुमति देने के लिए।

यदि आप जिस सिस्टम के साथ काम कर रहे हैं वह लीप सेकंड को संभाल नहीं सकता है, तो Bureau International des Poids et Mesures अनुशंसा करता है कि यूटीसी के बजाय टीएआई का उपयोग किया जाए।

देखें: http://tycho.usno.navy.mil/leapsec.html

स्रोत

2010-05-29 16:20:33

अब आपको इसके लिए अधिक अपवित्रता की आवश्यकता है, मुझे नहीं लगता कि लोग क्यों सोचते हैं कि पॉज़िक्स समय रैखिक होता है जब यह हर कुछ वर्षों में पीछे जाता है – Pacerier

Pacerier: यह पीछे की तरफ जाता है? गीज़। मुझे इसके बारे में पता नहीं था। मैंने सोचा कि यह पृथ्वी के धीमा घूर्णन के परिणामस्वरूप केवल आगे बढ़ गया है। –

यह वास्तव में इतिहास में पहले कभी नहीं था (यह भविष्य में * संभव * है) लेकिन हर 1.5 साल में औसत पर पीछे की ओर चला गया था। अगर हमारे पास स्टॉपवॉच है जो प्रत्येक आधे सेकेंड में विभाजित होता है, तो समय इस तरह जाता है: '58.0 58.5 59.0 59.5 00.0 00.5 00.0 00.5 01.0' http://en.wikipedia.org/wiki/Unix_time – Pacerier

क्या यूटीसी में समय स्टोर करने का कोई अच्छा कारण नहीं है?

उत्तर

संबंधित मुद्दे