डेलाइट सेविंग टाइम और टाइम ज़ोन बेस्ट प्रैक्टिस [बंद]

Question

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

यदि आपको कुछ भी जोड़ना है, तो कृपया करें

कई प्रणालियां सटीक समय रखने पर निर्भर हैं, समस्या दिन के उजाले की बचत के कारण समय के साथ होती है - घड़ी को आगे या पीछे ले जाना।

उदाहरण के लिए, किसी के पास ऑर्डर लेने की व्यवस्था में व्यावसायिक नियम होते हैं जो ऑर्डर के समय पर निर्भर करते हैं - यदि घड़ी बदलती है, तो नियम स्पष्ट नहीं हो सकते हैं। आदेश का समय कैसे जारी रहना चाहिए? निश्चित रूप से परिदृश्यों की एक अंतहीन संख्या है - यह केवल एक उदाहरण है।

• आपने डेलाइट सेविंग इश्यू से कैसे निपटा है?
• क्या धारणाएँ आपके समाधान का हिस्सा हैं? (यहां संदर्भ के लिए देख रहे हैं)

महत्वपूर्ण के रूप में, यदि ऐसा नहीं है:

• आपने क्या कोशिश की जो काम नहीं आई?
• काम क्यों नहीं किया?

मुझे प्रोग्रामिंग, ओएस, डेटा दृढ़ता और इस मुद्दे के अन्य प्रासंगिक पहलुओं में दिलचस्पी होगी।

सामान्य उत्तर बहुत अच्छे हैं, लेकिन मैं विवरण देखना चाहूंगा, खासकर यदि वे केवल एक मंच पर उपलब्ध हों।

Comments

@abatishchev - GETDATE()एसक्यूएल पर यह रास्ता यूटीसी (जैसा होगा DateTime.Now) होगा । और सर्वर किसी भी प्रकार के स्वचालित डीएसटी परिवर्तनों से प्रभावित नहीं होगा।

— Oded

@Oded: मैं सहमत हूँ कि क्या "सर्वर पर" जोड़ा जाएगा। लेकिन फिर भी यह अन्य अनुप्रयोगों को प्रभावित कर सकता है जिन्हें स्थानीय समय की आवश्यकता होती है। इसके द्वारा और अन्य कारणों से मुझे लगता है कि यूटीसी समय का स्पष्ट रूप से अनुरोध करना बेहतर है।

— abatishchev

यूटीसी को जीएमटी के लिए पसंद किया जाता है, क्योंकि यह अधिक सटीक रूप से परिभाषित है और क्योंकि कुछ ऑपरेटिंग सिस्टम पर जीएमटी की परिभाषा गड़बड़ है। लोगों के लिए "GMT" और "UTC" शब्दों को विनिमेय माना जा सकता है, लेकिन वे पूरी तरह से नहीं हैं। लगभग किसी भी सॉफ़्टवेयर / सिस्टम उद्देश्य के लिए, UTC का उपयोग करें। देखें stackoverflow.com/questions/2292334/…

— क्रिस जॉनसन 10

@ जोशस्टोडोला - जॉन स्कीट का ' उत्तर '।

— केनी एविट

@ ठीक है कि आप यह नहीं मान सकते कि सर्वर UTC पर होगा, मैंने उत्पादन सर्वरों को देखा है जहाँ समयक्षेत्र "UTC" था, लेकिन DST लागू था इसलिए वास्तव में UTC + 1 आधे से अधिक वर्षों से था। @Abatishchev के साथ सहमत होने के लिए स्पष्ट और उपयोग करें DateTime.UtcNowऔर GETUTCDATE(), यह अन्य देवों को भी दिखाता है जो आपने वास्तव में इसके बारे में सोचा है

— ono2012

Answer 1

उत्तर और अन्य डेटा का सारांश: (कृपया अपना जोड़ें)

करना:

• जब भी आप समय में एक सटीक क्षण का उल्लेख कर रहे हैं, तो एक एकीकृत मानक के अनुसार समय बनाए रखें जो दिन की बचत से प्रभावित नहीं है। (GMT और UTC इस संबंध में बराबर हैं, लेकिन UTC शब्द का उपयोग करना पसंद किया जाता है। ध्यान दें कि UTC को ज़ुलु या Z समय के रूप में भी जाना जाता है ।)
• यदि इसके बजाय आप स्थानीय समय मान का उपयोग करते हुए एक समय बनाए रखने के लिए चुनते हैं, तो UTC से इस विशेष समय के लिए स्थानीय समय ऑफ़सेट शामिल करें (यह ऑफ़सेट पूरे वर्ष में बदल सकता है), जैसे कि टाइमस्टैम्प को बाद में स्पष्ट रूप से व्याख्या किया जा सकता है।
• कुछ मामलों में, आपको यूटीसी समय और समकक्ष स्थानीय समय दोनों को स्टोर करने की आवश्यकता हो सकती है । अक्सर यह दो अलग-अलग क्षेत्रों के साथ किया जाता है, लेकिन कुछ प्लेटफ़ॉर्म एक datetimeoffsetप्रकार का समर्थन करते हैं जो एक ही क्षेत्र में दोनों को स्टोर कर सकते हैं।
• जब टाइमस्टैम्प को एक संख्यात्मक मान के रूप में संग्रहीत किया जाता है, तो यूनिक्स समय का उपयोग करें - जो कि पूरे सेकंड की संख्या है 1970-01-01T00:00:00Z(लीप सेकंड को छोड़कर)। यदि आपको उच्च परिशुद्धता की आवश्यकता है, तो इसके बजाय मिलीसेकंड का उपयोग करें। यह मान हमेशा किसी भी समय क्षेत्र समायोजन के बिना, यूटीसी पर आधारित होना चाहिए।
• यदि आपको बाद में टाइमस्टैम्प को संशोधित करने की आवश्यकता हो सकती है, तो मूल समय क्षेत्र आईडी को शामिल करें ताकि आप यह निर्धारित कर सकें कि ऑफसेट मूल मूल्य से बदल गया है या नहीं।
• भविष्य की घटनाओं का समय निर्धारण करते समय, आमतौर पर UTC के बजाय स्थानीय समय को प्राथमिकता दी जाती है, क्योंकि ऑफसेट बदलना आम बात है। उत्तर देखें , और ब्लॉग पोस्ट ।
• जब संपूर्ण तिथियां, जैसे कि जन्मदिन और वर्षगांठ संग्रहीत करते हैं, तो यूटीसी या किसी अन्य समय क्षेत्र में परिवर्तित न करें।
  • जब संभव हो, तो केवल तारीख डेटा प्रकार में स्टोर करें जिसमें दिन का समय शामिल नहीं है।
  • यदि ऐसा कोई प्रकार उपलब्ध नहीं है, तो मूल्य की व्याख्या करते समय हमेशा दिन के समय की अनदेखी करना सुनिश्चित करें। यदि आपको यह आश्वासन नहीं दिया जा सकता है कि समय की अनदेखी की जाएगी, तो उस दिन अधिक सुरक्षित प्रतिनिधि समय के रूप में 00:00 मध्यरात्रि के बजाय 12:00 दोपहर चुनें।
• याद रखें कि समय क्षेत्र ऑफ़सेट हमेशा एक पूर्णांक संख्या घंटे नहीं होते हैं (उदाहरण के लिए, भारतीय मानक समय UTC + 05: 30 है, और नेपाल UTC + 05: 45 का उपयोग करता है)।
• जावा, उपयोग का उपयोग कर java.time जावा 8 और बाद के लिए।
  • उस java.time कार्यक्षमता का अधिकांश भाग थ्री-बैक-बैकपोर्ट लाइब्रेरी में जावा 6 & 7 में वापस पोर्ट किया गया है ।
  • थ्रीटेनबप लाइब्रेरी में आगे के एंड्रॉइड (<26) के लिए अनुकूलित है।
  • ये परियोजनाएं आधिकारिक तौर पर रखरखाव-मोड में अब आदरणीय जोडा-टाइम को दबा देती हैं । Joda-Time, ThreeTen-Backport, ThreeTen-Extra , java.time क्लासेस और JSR 310 का नेतृत्व एक ही आदमी, स्टीफन कोलबोर्न करते हैं ।
• का उपयोग कर नेट , उपयोग करने पर विचार Noda समय ।
• यदि बिना Noda Time के .NET का उपयोग करते हैं, तो विचार करें कि DateTimeOffsetअक्सर एक बेहतर विकल्प है DateTime।
• यदि पर्ल का उपयोग कर रहे हैं, तो डेटटाइम का उपयोग करें ।
• यदि पायथन का उपयोग कर रहे हैं, तो पाइत्ज़ या डेट्यूटिल का उपयोग करें ।
• जावास्क्रिप्ट का उपयोग करते हैं, उपयोग moment.js साथ पल-समय क्षेत्र विस्तार।
• PHP> 5.2 का उपयोग करते समय DateTime, और DateTimeZoneकक्षाओं द्वारा प्रदान किए गए देशी समय क्षेत्र रूपांतरणों का उपयोग करें । उपयोग करते समय सावधान रहें DateTimeZone::listAbbreviations()- उत्तर देखें । ऑलसन डेटा के साथ PHP रखने के लिए, समय- समय पर टाइमज़ोनबेड PECL पैकेज स्थापित करें ; उत्तर देखें ।
• यदि C ++ का उपयोग कर रहे हैं, तो एक पुस्तकालय का उपयोग करना सुनिश्चित करें जो IANA टाइमज़ोन डेटाबेस का ठीक से उपयोग करता है । इनमें cctz , ICU और हॉवर्ड हिनान्ट की "tz" लाइब्रेरी शामिल हैं ।
  • समय क्षेत्र रूपांतरणों के लिए बूस्ट का उपयोग न करें । हालांकि इसके एपीआई मानक IANA (उर्फ "ज़ोनइन्फो") पहचानकर्ताओं का समर्थन करने का दावा करते हैं, लेकिन यह प्रत्येक क्षेत्र में होने वाले परिवर्तनों के समृद्ध इतिहास पर विचार किए बिना, उन्हें गंभीर रूप से POSIX- शैली डेटा के लिए मैप करता है। (इसके अलावा, फ़ाइल रखरखाव से बाहर हो गई है।)
• यदि जंग का उपयोग करते हैं, तो क्रोनो का उपयोग करें ।
• अधिकांश व्यावसायिक नियम यूटीसी या जीएमटी के बजाय नागरिक समय का उपयोग करते हैं। इसलिए, आवेदन तर्क को लागू करने से पहले UTC टाइमस्टैम्प को स्थानीय समय क्षेत्र में बदलने की योजना बनाएं।
• याद रखें कि समय क्षेत्र और ऑफसेट निश्चित नहीं हैं और बदल सकते हैं। उदाहरण के लिए, ऐतिहासिक रूप से यूएस और यूके ने 'स्प्रिंग फ़ॉरवर्ड' और 'फ़ॉल बैक' के लिए समान तिथियों का उपयोग किया था। हालांकि, 2007 में अमेरिका ने उन तारीखों को बदल दिया, जिन पर घड़ियों को बदला जाता है। अब इसका मतलब है कि वर्ष के 48 सप्ताह के लिए लंदन के समय और न्यूयॉर्क के समय के बीच का अंतर 5 घंटे और 4 सप्ताह (वसंत में 3, शरद ऋतु में 1) के लिए 4 घंटे है। किसी भी गणना में इस तरह की वस्तुओं से अवगत रहें, जिसमें कई क्षेत्र शामिल हैं।
• समय के प्रकार पर विचार करें (वास्तविक घटना समय, प्रसारण समय, सापेक्ष समय, ऐतिहासिक समय, आवर्ती समय) क्या तत्व (टाइमस्टैम्प, टाइम ज़ोन ऑफसेट और समय क्षेत्र का नाम) आपको सही पुनर्प्राप्ति के लिए स्टोर करने की आवश्यकता है - "समय के प्रकार" देखें यह जवाब ।
• अपने OS, डेटाबेस और एप्लिकेशन tzdata फ़ाइलों को सिंक में रखें, अपने और बाकी दुनिया के बीच।
• सर्वरों पर, हार्डवेयर घड़ियों और OS घड़ियों को स्थानीय समय क्षेत्र के बजाय UTC पर सेट करें।
• पिछले बुलेट बिंदु के बावजूद , वेब साइटों सहित सर्वर-साइड कोड, कभी भी सर्वर के स्थानीय समय क्षेत्र से विशेष रूप से कुछ भी होने की उम्मीद नहीं करनी चाहिए । उत्तर देखें ।
• अपने एप्लिकेशन कोड में केस-बाय-केस के आधार पर समय क्षेत्र के साथ काम करना पसंद करें, बजाय कॉन्फ़िगर फ़ाइल सेटिंग्स या चूक के विश्व स्तर पर।
• सभी सर्वरों पर NTP सेवाओं का उपयोग करें ।
• यदि FAT32 का उपयोग कर रहे हैं, तो याद रखें कि टाइमस्टैंप को स्थानीय समय में संग्रहीत किया जाता है, यूटीसी नहीं।
• आवर्ती घटनाओं (उदाहरण के लिए साप्ताहिक टीवी शो) के साथ काम करते समय, याद रखें कि समय डीएसटी के साथ बदलता है और समय क्षेत्र में भिन्न होगा।
• हमेशा कम-बाउंड समावेशी, ऊपरी-बाउंड अनन्य ( >=, <) के रूप में दिनांक-समय मान क्वेरी करें ।

मत करो:

• "टाइम ज़ोन" को भ्रमित न करें, जैसे America/New_York"टाइम ज़ोन ऑफ़सेट", जैसे -05:00। वे दो अलग चीजें हैं। टाइमजोन टैग विकि देखें ।
• Dateपुराने वेब ब्राउज़र में दिनांक और समय की गणना करने के लिए जावास्क्रिप्ट ऑब्जेक्ट का उपयोग न करें , क्योंकि ECMAScript 5.1 और निम्न में एक डिज़ाइन दोष है जो दिन के समय की बचत के समय का गलत तरीके से उपयोग कर सकता है। (यह ECMAScript 6/2015 में तय किया गया था)।
• ग्राहक की घड़ी पर कभी भरोसा न करें। यह बहुत अच्छी तरह से गलत हो सकता है।
• लोगों को "हमेशा यूटीसी हर जगह उपयोग करने" के लिए न कहें। इस व्यापक सलाह में कई वैध परिदृश्यों के बारे में बताया गया है जो इस दस्तावेज़ में पहले वर्णित हैं। इसके बजाय, जिस डेटा के साथ आप काम कर रहे हैं, उसके लिए उपयुक्त समय संदर्भ का उपयोग करें। ( टाइमस्टैम्पिंग यूटीसी का उपयोग कर सकते हैं, लेकिन भविष्य का समय निर्धारण और तारीख-केवल मान नहीं होना चाहिए।)

परिक्षण:

• परीक्षण करते समय, सुनिश्चित करें कि आप पश्चिमी, पूर्वी, उत्तरी और दक्षिणी गोलार्ध में (वास्तव में दुनिया के प्रत्येक तिमाही में, इसलिए 4 क्षेत्रों में) देशों का परीक्षण कर रहे हैं , दोनों डीएसटी प्रगति पर हैं और नहीं (8 देता है), और एक देश जो करता है डीएसटी का उपयोग न करें (सभी क्षेत्रों को कवर करने के लिए एक और 4, कुल मिलाकर 12 बना)।
• DST का परीक्षण संक्रमण, अर्थात जब आप वर्तमान में गर्मी के समय में हैं, तो सर्दियों से समय मान का चयन करें।
• टेस्ट सीमा मामले, जैसे कि एक समयक्षेत्र जो कि UTC + 12 है, डीएसटी के साथ, गर्मियों में स्थानीय समय UTC + 13 और यहां तक ​​कि सर्दियों में UTC + 13 भी हैं
• सभी तृतीय-पक्ष पुस्तकालयों और अनुप्रयोगों का परीक्षण करें और सुनिश्चित करें कि वे समय क्षेत्र डेटा को सही ढंग से संभालते हैं।
• कम से कम आधे घंटे का समय परीक्षण करें।

संदर्भ:

• timezoneस्टैक ओवरफ्लो पर विस्तृत टैग विकी पेज
• ओल्सन डेटाबेस, उर्फ ​​Tz_database
• ओट्सन डेटाबेस को बनाए रखने के लिए IETF मसौदा प्रक्रिया
• टाइम ज़ोन और डीएसटी के लिए स्रोत
• आईएसओ प्रारूप (आईएसओ 8601)
• यूनिकोड कंसोर्टियम से ओल्सन डेटाबेस और विंडोज टाइम ज़ोन आईडी के बीच मैपिंग
• विकिपीडिया पर समय क्षेत्र पृष्ठ
• StackOverflow प्रश्न टैग किए गए dst
• StackOverflow प्रश्न टैग किए गए timezone
• डीएसटी के साथ काम करना - माइक्रोसॉफ्ट डेटाइम सर्वोत्तम प्रथाओं
• विकिपीडिया पर नेटवर्क टाइम प्रोटोकॉल

अन्य:

• डीएसटी को समाप्त करने के लिए अपने प्रतिनिधि की पैरवी करें। हम हमेशा उम्मीद कर सकते हैं ...
• अर्थ स्टैंडर्ड टाइम के लिए लॉबी

Comments

GMT का उपयोग वास्तव में समस्या को हल नहीं करता है, फिर भी आपको यह पता लगाने की आवश्यकता है कि आवेदन करने के लिए सही डेल्टा क्या है, और यह वह जगह है जहां सभी जटिल झूठ हैं। डेल्टा उन प्रणालियों में निर्धारित करने के लिए जटिल हो सकता है जो विभिन्न क्षेत्रों में उपयोगकर्ताओं द्वारा उपयोग किए जाते हैं (विभिन्न दिन की बचत स्विच शेड्यूल के साथ) या ऐतिहासिक / भविष्य के डेटा दिखाने वाले सिस्टम में।

— केकरस

यदि सभी एप्लिकेशन को वर्तमान स्थानीय समय प्रदर्शित करना है तो यह सच है। लेकिन अगर हमारे पास उदाहरण के लिए ऑस्ट्रेलिया में एक सर्वर है जिसे 2 अप्रैल 2006 को कनाडा में लेन-देन के लिए तारीख / समय प्रदर्शित करने की आवश्यकता है (यह कनाडा में बदले गए डेलाइट सेविंग नियम बदलने से पहले अंतिम वर्ष था) - क्या आपके पास ओएस कॉल है वह डेटटाइम ("2006/04/02 14: 35Z") कर सकता है। ToLocalTime ()। WithDaylightSavingRules ("कनाडा", 2006)?

— केकरस

हां, विंडोज में ऐसा ओएस कॉल है - SystemTimeToTzSpecificLocation। msdn.microsoft.com/en-us/library/ms724949(VS.85).aspx

— माइकल मैडसेन

अगर आप लगातार आप कर सकते हैं तो @tchrist।

— पीटर अजताई

ध्यान रखें भविष्य की तारीखों (यहां तक ​​कि सिर्फ कल) को यूटीसी में परिवर्तित करने से आप हमेशा कुछ खो देते हैं। उदाहरण के लिए, आपने उस रूपांतरण को बनाने के लिए कुछ ज्ञात ऑफ़सेट का उपयोग किया था, लेकिन चूंकि यह तारीख भविष्य में है, इसलिए हमेशा एक मौका होता है कि जो समूह उन नियमों को सेट करता है, उन नियमों को बदल देगा। इसके अलावा, कुछ भविष्य की तारीखों को यूटीसी में बदलना लगभग असंभव है क्योंकि दिन के उजाले की बचत का समय उस वर्ष तक ज्ञात नहीं होता है (कुछ देश हर साल तारीखें निर्धारित करते हैं, 10+ वर्ष आगे या किसी निर्धारित नियमों के आधार पर नहीं)।

— eselk

Answer 2

मुझे यकीन नहीं है कि मैं उपरोक्त उत्तरों में क्या जोड़ सकता हूं, लेकिन यहां मेरे कुछ बिंदु हैं:

समय के प्रकार

चार अलग-अलग समय पर विचार करना चाहिए:

1. घटना का समय: उदाहरण के लिए, वह समय जब कोई अंतरराष्ट्रीय खेल प्रतियोगिता होती है, या एक राज्याभिषेक / मृत्यु / आदि। यह घटना के समय-क्षेत्र पर निर्भर करता है और दर्शक के नहीं।
2. टेलीविजन समय: उदाहरण के लिए, एक विशेष टीवी शो दुनिया भर में स्थानीय समय 9:00 पर प्रसारित किया जाता है। अपनी वेबसाइट पर परिणाम (अमेरिकन आइडल के कहने का) प्रकाशित करने के बारे में सोचते समय महत्वपूर्ण
3. सापेक्ष समय: उदाहरण के लिए: इस सवाल का 21 घंटे में एक खुला समापन है। यह प्रदर्शित करना आसान है
4. आवर्ती समय: जैसे: एक टीवी शो हर सोमवार को रात 9 बजे होता है, तब भी जब डीएसटी बदलता है।

ऐतिहासिक / वैकल्पिक समय भी है। ये कष्टप्रद हैं क्योंकि वे मानक समय तक वापस नहीं जा सकते हैं। जैसे: जूलियन तारीखें, शनि पर एक चंद्र कैलेंडर के अनुसार तारीखें, क्लिंगन कैलेंडर।

यूटीसी में टाइमस्टैम्प शुरू / समाप्त करना अच्छी तरह से काम करता है। 1 के लिए, आपको इवेंट के साथ एक इवेंट टाइमज़ोन नाम + ऑफ़सेट स्टोर करना होगा। 2 के लिए, आपको प्रत्येक क्षेत्र के साथ संग्रहीत एक स्थानीय समय पहचानकर्ता की आवश्यकता होती है और प्रत्येक दर्शक के लिए एक स्थानीय समयक्षेत्र नाम + ऑफसेट संग्रहीत होता है (आईपी से इसे प्राप्त करना संभव है यदि आप एक क्रंच में हैं)। 3 के लिए, UTC सेकंड में स्टोर करें और टाइमज़ोन की कोई आवश्यकता नहीं है। 4 एक विशेष मामला है 1 या 2 के आधार पर कि यह एक वैश्विक या एक स्थानीय घटना है, लेकिन आपको टाइमस्टैम्प पर एक स्टोर करने की भी आवश्यकता है ताकि आप यह बता सकें कि क्या इस घटना से पहले या बाद में एक टाइमज़ोन परिभाषा बदल गई है। यदि आपको ऐतिहासिक डेटा दिखाने की आवश्यकता है तो यह आवश्यक है।

भंडारण का समय

• हमेशा यूटीसी में समय स्टोर करें
• प्रदर्शन पर स्थानीय समय में कनवर्ट करें (डेटा को देखने वाले उपयोगकर्ता द्वारा परिभाषित किया जा रहा है)
• जब एक टाइमज़ोन संग्रहीत करते हैं, तो आपको नाम, टाइमस्टैम्प और ऑफ़सेट की आवश्यकता होती है। इसकी आवश्यकता है क्योंकि सरकारें कभी-कभी अपने टाइमज़ोन का अर्थ बदल देती हैं (जैसे: यूएस सरकार ने डीएसटी की तारीखें बदल दीं), और आपके आवेदन को चीजों को इनायत से संभालने की जरूरत है ... उदाहरण के लिए: सटीक टाइमस्टैम्प जब LOST के एपिसोड से पहले और बाद में दोनों जीएसटी नियम दिखाए गए बदला हुआ।

ऑफसेट और नाम

उपरोक्त का एक उदाहरण होगा:

फ़ुटबॉल विश्व कप फ़ाइनल गेम दक्षिण अफ्रीका (UTC + 2 - SAST) में 11 जुलाई, 2010 को 19:00 UTC में हुआ।

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

सिस्टम का समय

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

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

इसके अलावा, सभी बॉक्स पर ntpd चलाएं।

ग्राहकों

कभी भी मान्य क्लाइंट के रूप में आपके द्वारा प्राप्त मशीन से विश्वास न करें। उदाहरण के लिए, दिनांक: HTTP शीर्ष लेख, या जावास्क्रिप्टDate.getTime() कॉल। ये ठीक हैं जब अपारदर्शी पहचानकर्ता के रूप में उपयोग किया जाता है, या जब एक ही क्लाइंट पर एक सत्र के दौरान दिनांक गणित करते हैं, लेकिन सर्वर पर आपके पास इन मूल्यों को पार करने की कोशिश न करें। आपके ग्राहक NTP नहीं चलाते हैं, और जरूरी नहीं कि उनके BIOS घड़ी के लिए एक कार्यशील बैटरी हो।

सामान्य ज्ञान

अंत में, सरकारें कभी-कभी बहुत अजीब बातें करेंगी:

नीदरलैंड में मानक समय 1937-06-30 के माध्यम से 1909-05-01 से कानून द्वारा UTC से ठीक 19 मिनट और 32.13 सेकंड आगे था। इस समय क्षेत्र को HH: MM प्रारूप का उपयोग करके बिल्कुल नहीं दिखाया जा सकता है।

ठीक है, मुझे लगता है कि मैं कर रहा हूँ।

Comments

इस उत्तर में कुछ महान बिंदु हैं, मैं विशेष रूप से इस भाग को इंगित करना चाहता था "पुनरावृत्ति समय: उदाहरण के लिए: एक टीवी शो हर सोमवार को रात 9 बजे होता है, तब भी जब डीएसटी बदल जाता है" डीबी में यूटीसी में संग्रहीत समय और फिर प्रदर्शन के लिए परिवर्तित करने में मदद मिलती है। समय क्षेत्र के साथ काम करने के कई पेचीदा पहलू। हालांकि, डीएसटी बाधाओं को पार करने वाली "आवर्ती घटनाओं" को संभालना बहुत कठिन हो जाता है।

— जारेड हेल्स

सामान्य ज्ञान के लिए +1। सामग्री को दिलचस्प रखने से यह कार्य और अधिक सुखद हो जाता है, जिससे उत्पादकता में वृद्धि हो सकती है :)

— क्रिस

इस जवाब में बहुत सारी अच्छी चीजें, लेकिन कुछ मुद्दे। 1) कई समय क्षेत्र संक्षिप्त हैं। यहां देखें 2) हमेशा आप यूटीसी में स्टोर नहीं करना चाहते हैं। अधिकांश समय - हाँ, लेकिन संदर्भ मायने रखता है। आपके संदर्भ में, UTC में टेलीविज़न का समय संग्रहीत नहीं किया जाएगा। इसके अलावा, कभी-कभी इसके गैरकानूनी या नीति के खिलाफ स्थानीय समय को स्टोर नहीं करने के लिए - जो कि DateTimeOffset(या समतुल्य) जैसी चीजें काम में आती हैं। नहीं तो अच्छा लिखो।

— मैट जॉनसन-पिंट

इसलिए, हर कोई इस बात से सहमत है कि जॉडा पुस्तकालय अब तक का सबसे अच्छा उपकरण है। हालाँकि, हमें इस लेख ( joda.org/joda-time/tz_update.html ) के अनुसार नवीनतम टाइमज़ोन जानकारी के साथ अद्यतन रखने के लिए ( पुनः निर्माण ) जोडा जार फाइल को अपडेट करते रहना होगा। क्या IANA वेबसाइट ( iana.org/time-zones ) से नवीनतम टाइमज़ोन डेटा डाउनलोड करने और जोडा लाइब्रेरी के पुनर्निर्माण का कोई मानक तरीका है ? दूसरे शब्दों में, क्या मैन्युअल रूप से करने के बजाय इस प्रक्रिया को स्वचालित करना संभव है?

— saravana_pc

नीदरलैंड सामान्य ज्ञान वैध है। ietf.org/rfc/rfc3339.txt खंड 5.8। आधे रास्ते से लगा कि कोई हमारा पैर खींच रहा है।

— रफिन

Answer 3

यह एक महत्वपूर्ण और आश्चर्यजनक रूप से कठिन मुद्दा है। सच्चाई यह है कि लगातार समय के लिए पूरी तरह से संतोषजनक मानक नहीं है। उदाहरण के लिए, SQL मानक और ISO प्रारूप (ISO 8601) स्पष्ट रूप से पर्याप्त नहीं हैं।

वैचारिक दृष्टिकोण से, आमतौर पर दो प्रकार के टाइम-डेट डेटा के साथ सौदा होता है, और उन्हें भेद करने के लिए सुविधाजनक है (उपरोक्त मानक नहीं): " भौतिक समय " और " नागरिक समय " "।

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

एक "सिविल" समय एक डेटाइम विनिर्देश है जो नागरिक मानदंडों का पालन करता है: समय का एक बिंदु पूरी तरह से डेटाइम फ़ील्ड (वाई, एम, डी, एच, एम, एस, एफएस) प्लस एक टीबी (टाइमज़ोन विनिर्देश) के एक सेट द्वारा निर्दिष्ट किया गया है (वास्तव में एक "कैलेंडर" भी है, लेकिन हम ग्रेगोरियन कैलेंडर की चर्चा को प्रतिबंधित करते हैं)। एक समयक्षेत्र और एक कैलेंडर संयुक्त रूप से (सिद्धांत रूप में) एक प्रतिनिधित्व से दूसरे में मैप करने की अनुमति देता है। लेकिन नागरिक और भौतिक समय के सिद्धांत मौलिक रूप से विभिन्न प्रकार के परिमाण हैं, और उन्हें वैचारिक रूप से अलग और अलग तरीके से व्यवहार किया जाना चाहिए (एक सादृश्य: बाइट्स और चरित्र के तार)।

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

जॉन अपने कैलेंडर में डेटाटाइम 2019-Jul-27, 10:30:00, TZ = Chile/Santiago(जिसमें ऑफसेट GMT-4 है, इसलिए यह UTC से मेल खाता है 2019-Jul-27 14:30:00) में कुछ ईवेंट के लिए एक अनुस्मारक रिकॉर्ड करता है । लेकिन भविष्य में किसी दिन, देश टीटी ऑफसेट को जीएमटी -5 में बदलने का फैसला करता है।

अब, जब दिन आता है ... उस अनुस्मारक को ट्रिगर करना चाहिए

क) 2019-Jul-27 10:30:00 Chile/Santiago = UTC time 2019-Jul-27 15:30:00?

या

ब) 2019-Jul-27 9:30:00 Chile/Santiago = UTC time 2019-Jul-27 14:30:00?

कोई भी सही उत्तर नहीं है, जब तक कोई यह नहीं जानता कि जॉन को वैचारिक रूप से क्या मतलब है जब उसने कैलेंडर को बताया "कृपया मुझे अंगूठी दें।" 2019-Jul-27, 10:30:00 TZ=Chile/Santiago " कहा था।

क्या उनका मतलब "सिविल डेट-टाइम" था ("जब मेरे शहर की घड़ियां 10:30 बताती हैं")? उस मामले में, ए) सही उत्तर है।

या क्या उनका मतलब "भौतिक समय का तात्पर्य" था, जो हमारे ब्रह्मांड के समय की निरंतरता रेखा का एक बिंदु था, कहते हैं, "जब अगला सूर्य ग्रहण होता है"। उस मामले में, उत्तर बी) सही है।

कुछ दिनांक / समय एपीआई को यह अंतर प्राप्त होता है: उनमें से, जोड़ीटाइम , जो अगले (तीसरे!) जावा डेटटाइम एपीआई (जेएसआर 310) की नींव है।

Comments

एक अन्य बिंदु पर विचार करने के लिए जिसे मैंने एपीआई में नहीं देखा है, वह यह है कि जब समय और समय क्षेत्र दिया जाता है, तो भी कम से कम दो प्रशंसनीय अर्थ होते हैं जैसे "13: 00: 00EDT"। यह स्थानीय समय के अनुसार दोपहर 1 बजे होने वाली किसी ऐसी चीज का उल्लेख किया जा सकता है, जिसके बारे में माना जाता है कि यह पूर्वी डेलाइट टाइम थी, या ऐसा कुछ जिसे इस समय हुआ हो कि पूर्वी समय 13:00 तक माना जाता है, जिसे माना जाता है पूर्वी डेलाइट टाइम का पालन करते हुए एक जगह पर हुआ है। यदि किसी के पास कई टाइमस्टैम्प्स हैं, जहां समय-क्षेत्र की जानकारी गलत हो सकती है (जैसे डिजिटल कैमरा फाइलें) ...

— 17

... यह जानते हुए कि क्या वे एक सटीक स्थानीय समय या वैश्विक समय को दर्शाते हैं, यह निर्धारित करने में महत्वपूर्ण हो सकता है कि उन्हें कैसे ठीक किया जाए।

— सुपरकैट

स्पष्ट रूप से जॉन ए) चाहता है क्योंकि लोग 8:30 बजे काम करते हैं, जो भी वर्तमान में डीएसटी या टाइमज़ोन है। यदि वे डीएसटी में जाते हैं, तो वे 8:30 बजे काम पर जाएंगे, जब वे डीएसटी से बाहर निकलेंगे, तो वे 8:30 बजे काम पर जाएंगे। यदि देश एक और समयक्षेत्र में जाने का फैसला करता है, तो वे 8:30 बजे काम पर

— जाएंगे

Answer 4

चिंताओं का स्पष्ट रूप से अलग-अलग निर्धारण करना - यह जानने के लिए कि उपयोगकर्ताओं के साथ कौन-सा टियर इंटरैक्ट करता है, और विहित प्रतिनिधित्व / UTC से / के लिए दिनांक-समय बदलना पड़ता है। गैर-यूटीसी तिथि-समय प्रस्तुति है (उपयोगकर्ताओं के स्थानीय समयक्षेत्र के बाद), यूटीसी समय मॉडल है (बैक-एंड और मिड टियर्स के लिए अद्वितीय रहता है)।

इसके अलावा, यह तय करें कि आपके वास्तविक दर्शक क्या हैं, आपको क्या नहीं करना है और आप कहां रेखा खींचते हैं । जब तक आप वास्तव में महत्वपूर्ण ग्राहक नहीं हैं तब तक विदेशी कैलेंडर न छुएं और फिर उस क्षेत्र के लिए अलग-अलग उपयोगकर्ता-सामना करने वाले सर्वर पर विचार करें।

यदि आप उपयोगकर्ता के स्थान को प्राप्त कर सकते हैं और बनाए रख सकते हैं, तो व्यवस्थित दिनांक-समय रूपांतरण (जैसे .NET संस्कृति या एक SQL तालिका) के लिए स्थान का उपयोग करें, लेकिन एंड-यूज़र को ओवरराइड्स चुनने का एक तरीका प्रदान करें यदि आपके उपयोगकर्ताओं के लिए दिनांक-समय महत्वपूर्ण है।

यदि ऐतिहासिक ऑडिट बाध्यताएं शामिल हैं (जैसे कि जॉय इन एज़ ने सितंबर में 2 साल पहले बिल का भुगतान किया था) तो रिकॉर्ड के लिए यूटीसी और स्थानीय समय दोनों रखें (आपकी रूपांतरण तालिका एक समय में बदल जाएगी)।

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

दिनांक-समय के पाठीय प्रतिनिधित्व में एम्बेडेड टाइम-ज़ोन ऑफ़सेट पर भरोसा न करें और उन्हें पार्स करने और उनका पालन करने के लिए स्वीकार न करें। इसके बजाय हमेशा अनुरोध करें कि समय क्षेत्र और / या संदर्भ क्षेत्र को स्पष्ट रूप से परिभाषित किया जाना चाहिए । आप आसानी से पीएसटी ऑफसेट के साथ समय प्राप्त कर सकते हैं लेकिन समय वास्तव में ईएसटी है क्योंकि ग्राहक के संदर्भ समय और रिकॉर्ड बस एक सर्वर पर निर्यात किए गए थे जो पीएसटी में है।

Answer 5

आपको ओल्सन tz डेटाबेस के बारे में जानना होगा , जो ftp://elsie.nci.nih.gov/pub http://iana.org/time-zones/ से उपलब्ध है । दुनिया भर के विभिन्न देशों में सर्दी और गर्मी (मानक और दिन की बचत) समय के बीच स्विच करने के लिए (और चाहे) में अक्सर अंतिम-मिनट के परिवर्तनों से निपटने के लिए इसे प्रति वर्ष कई बार अपडेट किया जाता है। 2009 में, आखिरी रिलीज 2009 थी; 2010 में, यह 2010n था; 2011 में, यह 2011n था; मई 2012 के अंत में, रिलीज़ 2012 सी थी। ध्यान दें कि दो अलग अभिलेखागार (tzcode20xxy.tar.gz और tzdata20xxy.tar.gz) में डेटा और वास्तविक समय क्षेत्र डेटा को प्रबंधित करने के लिए कोड का एक सेट है। कोड और डेटा दोनों सार्वजनिक डोमेन में हैं।

यह समय क्षेत्र के नामों का स्रोत है जैसे अमेरिका / Los_Angeles (और समानार्थक शब्द जैसे US / प्रशांत)।

यदि आपको अलग-अलग ज़ोन का ट्रैक रखने की आवश्यकता है, तो आपको ओल्सन डेटाबेस की आवश्यकता है। जैसा कि दूसरों ने सलाह दी है, आप डेटा को एक निश्चित प्रारूप में भी संग्रहीत करना चाहते हैं - यूटीसी सामान्य रूप से चुना गया है - साथ ही उस समय क्षेत्र का रिकॉर्ड भी जिसमें डेटा उत्पन्न किया गया था। आप समय और समय क्षेत्र के नाम पर यूटीसी से ऑफसेट के बीच अंतर करना चाहते हैं; जो बाद में फर्क कर सकता है। इसके अलावा, यह जानते हुए कि यह वर्तमान में 2010-03-28T23: 47: 00-07: 00 (यूएस / प्रशांत) 2010-11-201TT12: 30 के मान की व्याख्या करने में आपकी मदद कर सकता है या नहीं कर सकता है - जो कि संभवतः पीएसटी में निर्दिष्ट है ( प्रशांत मानक समय) पीडीटी (पैसिफिक डेलाइट सेविंग टाइम) के बजाय।

मानक सी लाइब्रेरी इंटरफेस इस तरह के सामान के साथ भयानक रूप से सहायक नहीं हैं।

---

ओल्सन डेटा स्थानांतरित हो गया है, क्योंकि ई। ओल्सन जल्द ही सेवानिवृत्त हो जाएंगे, और भाग में क्योंकि कॉपीराइट उल्लंघन के लिए बनाए रखने वालों के खिलाफ एक (अब खारिज) कानून सूट था। टाइम ज़ोन डेटाबेस अब IANA , इंटरनेट असाइन किए गए नंबर प्राधिकरण के तत्वावधान में प्रबंधित किया जाता है , और 'टाइम ज़ोन डेटाबेस' के सामने पृष्ठ पर एक लिंक है । चर्चा मेलिंग सूची अब है [e-mail]; घोषणा सूची है [e-mail]।

Comments

ओल्सन डेटाबेस में ऐतिहासिक डेटा भी शामिल है, जो इसे डीएसटी से निपटने के लिए विशेष रूप से उपयोगी बनाता है। उदाहरण के लिए, यह जानता है कि यूएस में 31 मार्च, 2000 के अनुरूप एक यूटीसी मूल्य डीएसटी में नहीं है, लेकिन यूएस में 31 मार्च 2008 के अनुरूप एक यूटीसी मूल्य है।

— जोश केली

यूनिकोड कंसोर्टियम ओल्सन टोम ज़ोन आईडी और विंडोज टाइम ज़ोन आईडी के बीच एक मैपिंग बनाए रखता है: unicode.org/repos/cldr-tmp/trunk/diff/supplemental/…

— जोश मेले

यूनिकोड कंसोर्टियम के पेज के लिए अपडेटेड लिंक: unicode.org/repos/cldr-tmp/trunk/diff/supplemental/…

— Span

ओल्सन फ़ाइलों को पार्स करने के बारे में जानकारी कहां से मिल सकती है? मैं इसे एक db तालिका में संकलित करना चाहता हूं, लेकिन यह पता नहीं लगा सकता कि मुझे फ़ाइलों को कैसे पढ़ना चाहिए

— shealtiel

@gidireich: डेटा के साथ मुख्य जानकारी मिली है, और इसे समझना आसान नहीं है। इसके लिए मुख्य दस्तावेज zic.8मैन पेज (या zic.8.txt) में है। इस जानकारी को प्राप्त करने के लिए आपको tzcode2011i.tar.gzफ़ाइल के बजाय या साथ ही फ़ाइल की आवश्यकता होगी tzdata2011i.tar.gz।

— जोनाथन लेफ्लर

Answer 6

सामान्य तौर पर, संग्रहीत टाइमस्टैम्प में स्थानीय समय ऑफसेट (डीएसटी ऑफसेट सहित) शामिल हैं : अकेले यूटीसी पर्याप्त नहीं है यदि आप बाद में टाइमस्टैम्प को अपने मूल समय क्षेत्र (और डीएसटी सेटिंग) में प्रदर्शित करना चाहते हैं।

ध्यान रखें कि ऑफसेट हमेशा एक पूर्णांक संख्या नहीं होती है (जैसे भारतीय मानक समय UTC + 05: 30)।

उदाहरण के लिए, उपयुक्त प्रारूप एक टपल (यूनिक्स समय, मिनटों में ऑफसेट) या आईएसओ 8601 हैं ।

Comments

प्रदर्शन के लिए, ऑफसेट सही है। यदि आप परिवर्तन करना चाहते हैं, तो ऑफसेट अभी भी पर्याप्त नहीं है। आपको समय क्षेत्र भी जानना होगा क्योंकि नए मूल्य के लिए अलग ऑफसेट की आवश्यकता हो सकती है।

— मैट जॉनसन-पिंट

Answer 7

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

कुछ देश जैसे कि इज़राइल, ब्राजील, हर साल तय करते हैं कि उनकी दिन की बचत का समय कब है, इसलिए अग्रिम में यह जानना असंभव है कि कब (यदि) डीएसटी लागू होगा। अन्य लोगों ने (ish) नियम तय किए हैं जब DST लागू होता है। अन्य देश सभी के रूप में डीएसटी का उपयोग नहीं करते हैं।

Timezones को GMT से पूरे घंटे का अंतर नहीं होना चाहिए। नेपाल +5.45 है। यहां तक ​​कि टाइमज़ोन भी हैं जो कि +13 हैं। इसका मतलब है कि:

SUN 23:00 in Howland Island (-12)
MON 11:00 GMT 
TUE 00:00 in Tonga (+13)

सभी समान समय हैं, फिर भी 3 अलग-अलग दिन हैं!

टाइमज़ोन के लिए संक्षिप्त रूप में भी कोई स्पष्ट मानक नहीं है, और डीएसटी में जब वे बदलते हैं तो आप इस तरह से चीजों को समाप्त करते हैं:

AST Arab Standard Time     UTC+03
AST Arabian Standard Time  UTC+04
AST Arabic Standard Time   UTC+03

सबसे अच्छी सलाह है कि जितना हो सके स्थानीय समय से दूर रहें और UTC से चिपके रहें जहाँ आप कर सकते हैं। केवल अंतिम समय में स्थानीय समय में परिवर्तित करें।

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

Comments

इजरायल के बारे में - यह आधा सच है। हालांकि डीएसटी परिवर्तन का समय जूलियन कैलेंडर में एक विशिष्ट तारीख नहीं है - हिब्रू कैलेंडर के आधार पर एक नियम है (2014 में एक बदलाव हुआ था)। वैसे भी, सामान्य विचार सही है - यह चीजें एक बार में बदल सकती हैं और बदल सकती हैं

— यारोन यू।

इसके अलावा, एएसटी = अटलांटिक मानक समय। 'सर्वोत्तम सलाह' के लिए, यह एक शुरुआती बिंदु के रूप में ठीक है, लेकिन आपको इस पृष्ठ के बाकी हिस्सों को पढ़ने की ज़रूरत है, और थोड़ी प्रार्थना करें, और आप इसे थोड़ी देर के लिए ठीक कर सकते हैं।

— डेविडवेल

Answer 8

PHP के लिए:

PHP> 5.2 में डेटाइम ज़ोन क्लास पहले से ही ओल्सन डीबी पर आधारित है, जिसका अन्य लोग उल्लेख करते हैं, इसलिए यदि आप पीएचपी में टाइमज़ोन रूपांतरण कर रहे हैं और डीबी में नहीं, तो आप ओल्सन फ़ाइलों के साथ काम करने की छूट (हार्ड-टू-समझने) से मुक्त हैं।

हालाँकि, PHP को ओल्सन DB के रूप में बार-बार अपडेट नहीं किया जाता है, इसलिए बस PHPs समय क्षेत्र रूपांतरणों का उपयोग करके आपको पुरानी DST जानकारी के साथ छोड़ दिया जा सकता है और आपके डेटा की शुद्धता को प्रभावित कर सकता है। हालांकि यह अक्सर होने की उम्मीद नहीं है, यह हो सकता है, और होगा यदि आप उपयोगकर्ताओं की एक बड़ी आधार दुनिया भर में है होता है।

उपरोक्त समस्या से निपटने के लिए, टाइमज़ोनबेड पीईसीएल पैकेज का उपयोग करें । इसका कार्य PHP के टाइमज़ोन डेटा को अद्यतन करना है। इस पैकेज को जितनी बार अपडेट किया गया है, स्थापित करें। (मुझे यकीन नहीं है कि अगर इस पैकेज के अपडेट ओल्सन अपडेट का ठीक-ठीक पालन करते हैं, लेकिन यह एक आवृत्ति पर अपडेट किया गया लगता है, जो ओल्सन अपडेट की आवृत्ति के कम से कम बहुत करीब है।)

Answer 9

यदि आपका डिजाइन इसे समायोजित कर सकता है, तो स्थानीय समय रूपांतरण को एक साथ करने से बचें!

मुझे पता है कि यह कुछ अजीब लग सकता है, लेकिन UX के बारे में सोचें: उपयोगकर्ता नज़दीकी तारीखों (2010.09.17, शुक्रवार सेप्ट 17) की तुलना में नज़दीकी, सापेक्ष तिथियों (आज, कल, अगले सोमवार) पर प्रक्रिया करते हैं। और जब आप इसके बारे में अधिक सोचते हैं, तो टाइमज़ोन की सटीकता (और डीएसटी) अधिक महत्वपूर्ण होती है कि तारीख now()कितनी नजदीक है , इसलिए यदि आप तारीखों / डेटाइम को +/- 1 या 2 सप्ताह के लिए एक सापेक्ष प्रारूप में व्यक्त कर सकते हैं, तो बाकी की बात दिनांक UTC हो सकते हैं और यह 95% उपयोगकर्ताओं के लिए बहुत अधिक मायने नहीं रखता।

इस तरह से आप UTC में सभी तिथियों को संग्रहीत कर सकते हैं और UTC में सापेक्ष तुलना कर सकते हैं और केवल उपयोगकर्ता UTC तिथियों को अपने रिलेटिव डेट थ्रेशोल्ड के बाहर दिखा सकते हैं।

यह उपयोगकर्ता इनपुट पर भी लागू हो सकता है (लेकिन आम तौर पर अधिक सीमित फैशन में)। एक ड्रॉप डाउन से चयन करना जिसमें केवल {कल, आज, कल, अगला सोमवार, अगला गुरुवार} इतना सरल और आसान है कि उपयोगकर्ता के लिए एक तिथि पिकर है। डेट पिकर्स फॉर्म भरने के सबसे दर्दनाक दर्द उत्प्रेरण घटकों में से कुछ हैं। बेशक यह सभी मामलों के लिए काम नहीं करेगा लेकिन आप देख सकते हैं कि इसे बहुत शक्तिशाली बनाने के लिए केवल थोड़ा चतुर डिजाइन लेता है।

Answer 10

जब मैंने इसे आज़माया नहीं, तो समय क्षेत्र समायोजन के लिए एक दृष्टिकोण जो मुझे सम्मोहक लगता है वह इस प्रकार होगा:

1. यूटीसी में सब कुछ स्टोर करें।

2. TZOffsetsतीन स्तंभों के साथ एक तालिका बनाएँ : RegionClassId, StartDateTime, और OffsetMinutes (उदाहरण, मिनटों में)।

तालिका में, दिनांक और समय की एक सूची संग्रहीत करें जब से कितना स्थानीय समय बदल गया है, और। तालिका में क्षेत्रों की संख्या और तिथियों की संख्या इस बात पर निर्भर करेगी कि आपको दुनिया की किन तारीखों और क्षेत्रों का समर्थन करना है। इसे ऐसे समझें कि यह "ऐतिहासिक" तारीख है, भले ही तारीखों में भविष्य को कुछ व्यावहारिक सीमा तक शामिल किया जाना चाहिए।

जब आपको किसी भी यूटीसी समय के स्थानीय समय की गणना करने की आवश्यकता होती है, तो बस यह करें:

SELECT DATEADD('m', SUM(OffsetMinutes), @inputdatetime) AS LocalDateTime
FROM   TZOffsets
WHERE  StartDateTime <= @inputdatetime
       AND RegionClassId = @RegionClassId;

आप अपने ऐप में इस तालिका को कैश कर सकते हैं और डेटाबेस को टटोलने के बजाय LINQ या कुछ समान साधनों का उपयोग कर सकते हैं।

यह डेटा पब्लिक डोमेन tz डेटाबेस से डिस्टिल्ड किया जा सकता है ।

इस दृष्टिकोण के लाभ और फ़ुटनोट्स:

1. किसी भी नियम को कोड में बेक नहीं किया जाता है, आप नए क्षेत्रों या दिनांक सीमाओं के लिए ऑफ़सेट को आसानी से समायोजित कर सकते हैं।
2. आपको तिथियों या क्षेत्रों की प्रत्येक श्रेणी का समर्थन करने की आवश्यकता नहीं है, आप उन्हें आवश्यकतानुसार जोड़ सकते हैं।
3. क्षेत्रों को सीधे तौर पर भू-राजनीतिक सीमाओं के अनुरूप नहीं होना पड़ता है, और पंक्तियों के दोहराव से बचने के लिए (उदाहरण के लिए, यूएस में अधिकांश राज्य इसी तरह से डीएसटी को संभालते हैं), आपके पास व्यापक रीजनल क्लैस प्रविष्टियाँ हो सकती हैं जो किसी अन्य तालिका में लिंक को और अधिक पारंपरिक सूचियों में शामिल करती हैं। राज्य, देश इत्यादि।
4. यूएस जैसी स्थितियों के लिए जहां पिछले कुछ वर्षों में डीएसटी की शुरुआत और समाप्ति की तारीख बदल गई है, इससे निपटना बहुत आसान है।
5. चूंकि StartDateTime क्षेत्र एक समय के रूप में अच्छी तरह से स्टोर कर सकता है, 2:00 AM मानक परिवर्तन-ओवर समय आसानी से नियंत्रित किया जाता है।
6. दुनिया में हर जगह 1 घंटे के डीएसटी का उपयोग नहीं किया जाता है। यह उन मामलों को आसानी से संभालता है।
7. डेटा टेबल क्रॉस-प्लेटफ़ॉर्म है और एक अलग ओपन-सोर्स प्रोजेक्ट हो सकता है जो डेवलपर्स द्वारा उपयोग किया जा सकता है जो लगभग किसी भी डेटाबेस प्लेटफ़ॉर्म या प्रोग्रामिंग भाषा का उपयोग करते हैं।
8. इसका उपयोग उन ऑफसेट के लिए किया जा सकता है जिनका समय क्षेत्र से कोई लेना-देना नहीं है। उदाहरण के लिए, 1-सेकंड समायोजन जो समय-समय पर पृथ्वी के रोटेशन, ग्रेगोरियन कैलेंडर के भीतर और भीतर ऐतिहासिक समायोजन, आदि के लिए समायोजित करने के लिए होता है।
9. चूंकि यह एक डेटाबेस तालिका में है, मानक रिपोर्ट क्वेरी आदि, व्यापार तर्क कोड के माध्यम से यात्रा के बिना डेटा का लाभ उठा सकते हैं।
10. यह समय क्षेत्र ऑफ़सेट्स को संभालता है यदि आप इसे चाहते हैं, और यहां तक ​​कि विशेष ऐतिहासिक मामलों के लिए भी जिम्मेदार हो सकते हैं जहां एक क्षेत्र को किसी अन्य समय क्षेत्र को सौंपा गया है। आपको बस एक प्रारंभिक तारीख की आवश्यकता होती है जो प्रत्येक क्षेत्र को न्यूनतम आरंभ तिथि के साथ एक समय क्षेत्र ऑफसेट प्रदान करती है। इसके लिए प्रत्येक समय क्षेत्र के लिए कम से कम एक क्षेत्र बनाने की आवश्यकता होगी, लेकिन आप दिलचस्प सवाल पूछ सकते हैं जैसे: "2 फरवरी 1989 को सुबह 5:00 बजे, युमा, एरिज़ोना और सिएटल, वाशिंगटन के बीच स्थानीय समय में क्या अंतर है?" (बस एक एसयूएम (दूसरे से) को घटाएं)।

अब, इस दृष्टिकोण का ही नुकसान या किसी अन्य शब्दों में, रूपांतरण है से स्थानीय समय जीएमटी करने के लिए उपयुक्त नहीं हैं, के बाद से किसी भी डीएसटी परिवर्तन एक नकारात्मक घड़ी को ऑफसेट है कि दोहराता है किसी दिए गए स्थानीय समय। उस एक से निपटने का कोई आसान तरीका नहीं है, मुझे डर है, जो एक कारण है स्थानीय समय में भंडारण करना पहली जगह में बुरी खबर है।

Comments

आपका डेटाबेस विचार ओल्सन डेटाबेस के रूप में पहले ही लागू हो चुका है। जबकि दिन के उजाले की बचत का समय एक ओवरलैप बनाता है जो दिन के समय को निर्दिष्ट करता है विशिष्ट समय क्षेत्र को हल करने में मदद कर सकता है। 2:15 ईएसटी और 2:15 EDT अलग-अलग समय हैं। जैसा कि अन्य पोस्ट में कहा गया है कि ऑफसेट निर्दिष्ट करने से अस्पष्टता का भी समाधान होता है।

— बिलथोर 23

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

— मैट जॉनसन-पिंट

अपना खुद का डेटाबेस न बनाएं : हमेशा सिस्टम के एपीआई पर भरोसा करें!

— एलेक्स

Answer 11

मुझे हाल ही में एक वेब एप्लिकेशन में एक समस्या थी, जहां एक अजाक्स पोस्ट-बैक-डेटटाइम पर मेरे सर्वर-साइड कोड पर वापस आ रहा था जो डेटटाइम से अलग था।

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

अंत में मैंने पूरी तरह से क्लाइंट पर तारीख और समय की गणना को हटाने का विकल्प चुना, और एक पूर्णांक कुंजी पर अपने सर्वर पर वापस पोस्ट किया, जो तब लगातार परिवर्तन के लिए अनुमति देने के लिए, सर्वर पर तारीख के समय का अनुवाद किया गया।

इससे मेरी सीख: जब तक आपको ABSOLUTELY नहीं करना है, तब तक वेब अनुप्रयोगों में JavaScript दिनांक और समय की गणना का उपयोग न करें।

Comments

जावास्क्रिप्ट क्लाइंट मशीन पर चलता है, सर्वर मशीन पर नहीं। जावास्क्रिप्ट का आधार डेटाइम क्लाइंट का डेटटाइम है, न कि सर्वर का डेटटाइम।

— बालुसक

हाय बालूसी। मैं इसे समझता हूं (मेरी मूल पोस्ट से: "क्लाइंट पर javacode स्क्रिप्ट जिसने तिथि बनाई है ...")। मेरा मुद्दा यह था कि कुछ ग्राहक मशीन ने डीएसटी को एक तरीके से संसाधित किया, और कुछ अन्य ने दूसरे तरीके से। इसलिए मैंने ब्राउज़र अजीबता को रोकने के लिए उस सभी प्रोसेसिंग सर्वर-साइड को स्थानांतरित कर दिया

— जौन

@ जून- और जावास्क्रिप्ट कार्यान्वयन में कीड़े हैं जिन्हें आप पता नहीं लगा सकते हैं या इसके लिए अनुमति नहीं दे सकते हैं। तो हाँ, कभी भी क्लाइंट-साइड ECMAScript की गणना का उपयोग उन चीज़ों के लिए न करें जो मायने रखती हैं (हालाँकि आप बहुत अच्छा काम कर सकते हैं अन्यथा)।

— रॉब

Answer 12

मैंने इसे दो प्रकार के सिस्टम, "शिफ्ट प्लानिंग सिस्टम (जैसे फ़ैक्टरी वर्कर्स)" और "गैस डिपेंडेंट मैनेजमेंट सिस्टम" ... पर मारा है।

23 और 25 घंटे लंबे दिनों के साथ सामना करने के लिए एक दर्द है, तो 8hr पारियां हैं जो 7hr या 9hr लेती हैं। समस्या यह है कि आप पाएंगे कि प्रत्येक ग्राहक या यहां तक ​​कि ग्राहक के विभाग में उनके द्वारा बनाए गए अलग-अलग नियम हैं (अक्सर बिना दस्तावेज के) वे इन विशेष मामलों में क्या करते हैं।

कुछ सवाल ग्राहक से तब तक नहीं पूछे जाते, जब तक कि वे आपके "शेल्फ" सॉफ़्टवेयर के लिए भुगतान न कर दें। सॉफ़्टवेयर खरीदते समय इस प्रकार के मुद्दे के बारे में सोचने वाले ग्राहक को ढूंढना बहुत दुर्लभ है।

मुझे लगता है कि सभी मामलों में आपको UTC में समय रिकॉर्ड करना चाहिए और दिनांक / समय को संग्रहीत करने से पहले स्थानीय समय से / में परिवर्तित करना चाहिए। हालाँकि यह भी जानते हैं कि कौन सा समय लगता है, डेलाइट सेविंग और टाइम ज़ोन के साथ कठिन हो सकता है।

Comments

मेरी प्रेमिका, एक नर्स, रात में काम करती है और उन्हें डीएसटी स्विचओवर के दौरान टाइमजोन लिखना पड़ता है। उदाहरण के लिए, 2AM सीएसटी बनाम 2AM सीडीटी

— जो फिलिप्स

हां, यह सामान्य है: जब आप दैनिक (औसत) एक (सिविल) गणना करते हैं, तो आपको 23, 24 या 25 घंटों के दिनों का सामना करना पड़ता है। परिणामस्वरूप, जब आप 1 दिन जोड़ते हैं तो यह 24 घंटे नहीं जुड़ता है ! दूसरा, अपना खुद का टाइमज़ोन कोड बनाने की कोशिश न करें; केवल सिस्टम API का उपयोग करें। और अप-टू-डेट टाइमज़ोन डेटाबेस प्राप्त करने के लिए प्रत्येक तैनात सिस्टम को अपडेट करना न भूलें ।

— एलेक्स

Answer 13

वेब के लिए, नियम इतने जटिल नहीं हैं ...

• सर्वर-साइड, यूटीसी का उपयोग करें
• क्लाइंट-साइड, ओल्सन का उपयोग करें
  • कारण: UTC- ऑफ़सेट दिन की बचत-सुरक्षित नहीं हैं (जैसे कि न्यूयॉर्क ईएसटी (UTC - 5 घंटे) वर्ष का हिस्सा है, EDT (UTC - 4 घंटे) वर्ष का बाकी है।
  • क्लाइंट-साइड टाइम ज़ोन निर्धारण के लिए, आपके पास दो विकल्प हैं:
    • 1) उपयोगकर्ता सेट ज़ोन (सुरक्षित) है
      • संसाधन: वेब-तैयार ओल्सन tz HTML ड्रॉपडाउन और JSON
    • 2) ऑटो-डिटेक्ट ज़ोन
      • संसाधन: jsTimezoneDetect

बाकी आपके सर्वर-साइड डेटाइम पुस्तकालयों का उपयोग करके बस यूटीसी / स्थानीय रूपांतरण है। जाना अच्छा है...

Comments

यह शुरुआती बिंदु के रूप में अच्छी सलाह है, लेकिन यह पूरी तरह से आवेदन पर निर्भर करता है। यह एक अनुकूल वेबसाइट के लिए ठीक हो सकता है, लेकिन अगर आपके आवेदन पर कोई कानूनी / अधिकार क्षेत्र / वित्तीय पहलू है कि कोई व्यक्ति पर मुकदमा कर सकता है (मैंने कई पर काम किया है), तो यह एक अति-सरलीकरण है क्योंकि विभिन्न प्रकार के हैं ' समय ’, जैसा कि इस पृष्ठ पर अन्यत्र दिया गया है।

— डेविडवले

Answer 14

जब सर्वर पर चलने वाले एप्लिकेशन की बात आती है वेब और अन्य बैक-एंड सेवाओं सहित , तो के समय क्षेत्र की सेटिंग को एप्लिकेशन द्वारा अनदेखा कर दिया जाना चाहिए।

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

सर्वर-साइड कोड, वेब साइटों सहित, कभी भी सर्वर के स्थानीय समय क्षेत्र की अपेक्षा नहीं करनी चाहिए विशेष रूप से कुछ भी।

कुछ भाषाओं में, स्थानीय समय क्षेत्र आसानी से एप्लिकेशन कोड में रेंग सकता है। उदाहरण के लिए, DateTime.ToUniversalTime.NET में विधि परिवर्तित कर देंगे से यूटीसी को स्थानीय समय क्षेत्र, और DateTime.Nowसंपत्ति स्थानीय समय क्षेत्र में वर्तमान समय देता है। यह भीDate जावास्क्रिप्ट में कंस्ट्रक्टर कंप्यूटर के स्थानीय समय क्षेत्र का उपयोग करता है। इस तरह के कई अन्य उदाहरण हैं। कंप्यूटर के स्थानीय समय क्षेत्र सेटिंग का उपयोग करने वाले किसी भी कोड से बचने के लिए, रक्षात्मक प्रोग्रामिंग का अभ्यास करना महत्वपूर्ण है।

क्लाइंट साइड कोड, जैसे डेस्कटॉप एप्लिकेशन, मोबाइल एप्लिकेशन और क्लाइंट साइड जावास्क्रिप्ट के लिए स्थानीय समय क्षेत्र का उपयोग करके रिजर्व।

Answer 15

अपने सर्वर को UTC पर सेट रखें, और सुनिश्चित करें कि वे सभी ntp या समकक्ष के लिए कॉन्फ़िगर किए गए हैं।

यूटीसी दिन के समय बचत के मुद्दों से बचा जाता है, और आउट-ऑफ-सिंक सर्वर अप्रत्याशित परिणाम पैदा कर सकते हैं जो निदान करने में थोड़ी देर लगते हैं।

Answer 16

FAT32 फाइलसिस्टम में संग्रहीत टाइमस्टैम्प से निपटने के दौरान सावधान रहें - यह हमेशा स्थानीय समय के निर्देशांक (जिसमें DST - msdn लेख देखें ) में बनी रहती है। उस एक पर जल गया।

Comments

महान बिंदु। NTFS को यह समस्या नहीं है, लेकिन कुछ लोग अभी भी FAT32 का उपयोग करते हैं - विशेष रूप से USB कुंजी पर।

— मैट जॉनसन-पिंट

Answer 17

एक और बात, सुनिश्चित करें कि सर्वरों पर दिन के उजाले की बचत पैच लागू है।

हमारे पास पिछले साल एक स्थिति थी, जहां हमारा समय उत्तरी अमेरिकी उपयोगकर्ताओं के लिए तीन सप्ताह की अवधि के लिए एक घंटे से लगातार बाहर था, भले ही हम यूटीसी आधारित प्रणाली का उपयोग कर रहे थे।

यह सर्वर था अंत में यह पता चला है। उन्हें बस अप-टू-डेट पैच अप्लाई ( विंडोज सर्वर 2003 ) की जरूरत थी।

Answer 18

PHP का DateTimeZone::listAbbreviations()आउटपुट

यह PHP विधि कुछ 'प्रमुख' टाइमज़ोन (CEST की तरह) युक्त एक सहयोगी सरणी देता है, जो अपने आप में अधिक विशिष्ट 'भौगोलिक' टाइमज़ोन (जैसे यूरोप / एम्स्टर्डम) होते हैं।

यदि आप इन टाइमज़ोन और उनकी ऑफसेट / डीएसटी जानकारी का उपयोग कर रहे हैं, तो निम्नलिखित का एहसास करना बेहद जरूरी है:

ऐसा लगता है कि प्रत्येक टाइमज़ोन के सभी अलग-अलग ऑफसेट / डीएसटी कॉन्फ़िगरेशन (ऐतिहासिक कॉन्फ़िगरेशन सहित) शामिल हैं!

उदाहरण के लिए, यूरोप / एम्स्टर्डम इस समारोह के उत्पादन में छह बार पाया जा सकता है। 1937 तक उपयोग किए गए एम्स्टर्डम समय के लिए दो घटनाएँ (ऑफसेट 1172/4772) हैं; दो (1200/4800) उस समय के लिए हैं जो 1937 और 1940 के बीच इस्तेमाल किया गया था; और दो (3600/4800) 1940 के बाद से इस्तेमाल होने वाले समय के लिए हैं।

इसलिए, आप वर्तमान में सही / उपयोग में होने के नाते इस फ़ंक्शन द्वारा लौटाए गए ऑफसेट / डीएसटी जानकारी पर भरोसा नहीं कर सकते हैं!

यदि आप एक निश्चित समय क्षेत्र के वर्तमान ऑफसेट / डीएसटी को जानना चाहते हैं, तो आपको कुछ इस तरह करना होगा:

<?php
$now = new DateTime(null, new DateTimeZone('Europe/Amsterdam'));
echo $now->getOffset();
?>

Answer 19

यदि आप डेटाबेस सिस्टम को बनाए रखने के लिए होते हैं जो डीएसटी के साथ सक्रिय हैं, तो ध्यान से जांच करें कि क्या गिरावट में संक्रमण के दौरान उन्हें बंद करने की आवश्यकता है। मैंडी डीबीएस (या अन्य प्रणालियों के साथ) एक ही बिंदु (स्थानीय) समय में दो बार पास करना पसंद नहीं करते हैं, जो ठीक उसी समय होता है जब आप घड़ी में वापस आते हैं। SAP ने इसे (IMHO वास्तव में साफ) वर्कअराउंड के साथ हल किया है - घड़ी को वापस करने के बजाय, उन्होंने सिर्फ आंतरिक घड़ी को दो घंटे के लिए सामान्य गति से आधा चलने दिया ...

Answer 20

क्या आप .NET फ्रेमवर्क का उपयोग कर रहे हैं ? यदि ऐसा है, तो मुझे आपको DateTimeOffset प्रकार से परिचित कराना है , .NET 3.5 के साथ जोड़ा।

यह संरचना एक DateTimeऔर एक ऑफसेट ( TimeSpan) दोनों रखती है , जो DateTimeOffsetउदाहरण की तारीख और समय और समन्वित यूनिवर्सल टाइम (UTC) के बीच अंतर को निर्दिष्ट करती है ।

• DateTimeOffset.Nowस्थिर विधि एक वापस आ जाएगी DateTimeOffset वर्तमान (स्थानीय) समय से मिलकर उदाहरण है, और स्थानीय ऑफसेट (के रूप में ऑपरेटिंग सिस्टम की क्षेत्रीय जानकारी में परिभाषित)।

• DateTimeOffset.UtcNowस्थिर विधि एक वापस आ जाएगी DateTimeOffsetयूटीसी में वर्तमान समय से मिलकर उदाहरण (जैसे कि आप ग्रीनविच में थे)।

अन्य सहायक प्रकार TimeZone और TimeZoneInfo वर्ग हैं।

Comments

यह प्रस्तुत समस्या का समाधान नहीं है।

— कारदेरी

Answer 21

.NET पर इससे जूझने वालों के लिए , देखें कि क्या उपयोग DateTimeOffsetऔर / या TimeZoneInfoआपके समय के लायक है।

यदि आप IANA / Olson समय क्षेत्र का उपयोग करना चाहते हैं , या अपनी आवश्यकताओं के लिए निर्मित प्रकारों को अपर्याप्त पाते हैं, तो Noda Time की जाँच करें , जो .NET के लिए बहुत अधिक स्मार्ट दिनांक और समय API प्रदान करता है।

Answer 22

व्यावसायिक नियमों को हमेशा सिविल समय पर काम करना चाहिए (जब तक कि कोई कानून नहीं है जो अन्यथा कहता है)। ध्यान रखें कि नागरिक समय एक गड़बड़ है, लेकिन यह लोग इसका उपयोग करते हैं इसलिए यह महत्वपूर्ण है।

आंतरिक रूप से, टाइमस्टैम्प को नागरिक-समय-सेकंड-से-युग की तरह कुछ में रखें। युग में विशेष रूप से बात नहीं (मैं एहसान करता है यूनिक्स काल ) लेकिन यह मेकअप बातें विकल्प की तुलना में आसान है। मान लें कि छलांग सेकंड जब तक आप कुछ कर रहे हैं जो मौजूद नहीं वास्तव में उन्हें (उदाहरण के लिए, उपग्रह ट्रैकिंग) की जरूरत है। टाइमस्टैम्प और प्रदर्शित समय के बीच मानचित्रण एकमात्र बिंदु है जहां डीएसटी नियमों को लागू किया जाना चाहिए; नियम बार-बार बदलते हैं (वैश्विक स्तर पर, वर्ष में कई बार; राजनेताओं को दोष देते हैं) इसलिए आपको यह सुनिश्चित करना चाहिए कि आप मैपिंग को हार्ड-कोड न करें। ओल्सन का टीबी डेटाबेस अमूल्य है।

Comments

यहां समस्या यह है कि नागरिक समय (उर्फ कैलेंडर समय) समय में एक पल का भी ठीक से प्रतिनिधित्व नहीं करता है। यदि आप सेकंड-ए-एपोच दृष्टिकोण लेते हैं, तो क्या आप वास्तव में हर उस क्षण को ध्यान में रखते हैं, जो दिन के उजाले में बदलाव के लिए छोड़ दिया गया था या फिर से पलट गया था? शायद ऩही। युग आधार केवल यूटीसी या कुछ अन्य निश्चित, तात्कालिक समय के संदर्भ में काम करता है।

— मैट जॉनसन-पिंट

@MattJohnson इसलिए "व्यापार नियम" हिस्सा है। यदि नियम कहते हैं कि सुबह 2:30 बजे (या जो भी समय) कुछ होता है, वह वर्ष में एक दिन दो बार और वर्ष में एक दिन कभी नहीं होगा। यदि ग्राहक नियम स्पष्ट नहीं करते हैं, तो यही होगा ।

— user253751

नागरिक समय में आंतरिक टाइमस्टैम्प रखना बहुत मुश्किल हो सकता है। एक सेकंड के बाद से इसे सेकंड के रूप में रखना अभी भी मुश्किल है, मैं सीधा खतरनाक कहूंगा। मुझे यकीन है कि लोग ऐसा कर रहे हैं, और यह संभव हो सकता है कि जब आप सुपर सावधान रहें तो अधिकांश समय इसे ठीक से काम करना संभव हो, लेकिन इसे सबसे अच्छा अभ्यास या सामान्य सिफारिश नहीं माना जा सकता है।

— स्टीव समिट

Answer 23

बस दो चीजों को इंगित करना चाहता था जो गलत या कम से कम भ्रामक लगती हैं:

हमेशा एक एकीकृत मानक के अनुसार समय बनाए रखें जो दिन की बचत से प्रभावित न हो। GMT और UTC का उल्लेख अलग-अलग लोगों द्वारा किया गया है, हालांकि UTC का उल्लेख सबसे अधिक बार किया गया है।

(लगभग) सभी व्यावहारिक कंप्यूटिंग उद्देश्यों के लिए, UTC, वास्तव में, GMT है। जब तक आप एक भिन्नात्मक सेकंड के साथ टाइमस्टैम्प नहीं देखते हैं, आप GMT के साथ काम कर रहे हैं जो इस अंतर को बेमानी बनाता है।

टाइमस्टैम्प का भंडारण करते समय (डीएसटी ऑफसेट सहित) स्थानीय समय ऑफसेट को शामिल करें।

एक टाइमस्टैम्प को हमेशा GMT में दर्शाया जाता है और इस प्रकार कोई ऑफसेट नहीं होता है।

Comments

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

— nogridbag

हां, UTC और GMT ऑफसेट को छोड़कर उलटा है। उदाहरण के लिए UTC-0700 GMT + 0700 के समान है। वास्तव में, सब कुछ डिजिटल इन दिनों UTC का उपयोग किया जाना चाहिए।

— मैट जॉनसन-पिंट

@ मैट: क्या आप यूटीसी और जीएमटी ऑफसेट के उलट हैं? मैं उस पर कहां पढ़ सकता हूं?

— रेटो होहनेर

दरअसल, मुझे लगता है कि मैं पहले गलत था। GMT और UTC स्वयं उलटे नहीं हैं। यह है कि कार्यान्वयन हैं जो उन्हें उलटा दिखाते हैं, जैसे कि IANA / Olson / TZDB डेटाबेस। देखें यहाँ । एक और क्षेत्र जिसे आप व्युत्क्रम में देख रहे हैं वह जावास्क्रिप्ट के getTimezoneOffset () फ़ंक्शन में है।

— मैट जॉनसन-पिंट

@MattJohnson: वे हैक हैं और उन्हें समाप्त कर दिया जाना चाहिए।

— एलिक्स एक्सल

Answer 24

यहाँ मेरा अनुभव है: -

(किसी तीसरे पक्ष के पुस्तकालय की आवश्यकता नहीं है)

• सर्वर-साइड पर, यूटीसी प्रारूप में बार स्टोर करें ताकि डेटाबेस में सभी दिनांक / समय मान उपयोगकर्ताओं, सर्वर, टाइमज़ोन या डीएसटी के स्थान की परवाह किए बिना एक ही मानक में हों।
• यूआई परत पर या उपयोगकर्ता को भेजे गए ईमेल में, आपको उपयोगकर्ता के अनुसार समय दिखाने की आवश्यकता है। उस मामले के लिए, आपको उपयोगकर्ता के टाइमज़ोन ऑफ़सेट की आवश्यकता होगी ताकि आप इस ऑफ़सेट को अपने डेटाबेस के UTC मान में जोड़ सकें, जिसके परिणामस्वरूप उपयोगकर्ता का स्थानीय समय समाप्त हो जाएगा। जब आप साइन अप कर रहे होते हैं तो आप उपयोगकर्ता के टाइमज़ोन ऑफसेट या तो ले सकते हैं या आप उन्हें वेब और मोबाइल प्लेटफ़ॉर्म में ऑटो-डिटेक्ट कर सकते हैं। वेबसाइटों के लिए, जावास्क्रिप्ट फ़ंक्शन getTimezoneOffset () विधि संस्करण 1.0 से एक मानक है और सभी ब्राउज़रों के साथ संगत है। (रेफरी: http://www.w3schools.com/jsref/jsref_getTimezoneOffset.asp )

Comments

जब आप डीएसटी परिवर्तनों पर विचार करते हैं तो यह काम नहीं करता है। getTimezoneOffsetउस दिनांक और समय के लिए ऑफ़सेट लौटाता है जब आप उसे कॉल करते हैं। जब डे टाइम सेविंग टाइम में या उसके बाहर टाइम ज़ोन में बदलाव होता है तो ऑफसेट बदल सकता है। टाइमजोन टैग विकी में "टाइम ज़ोन! = ऑफसेट" देखें ।

— मैट जॉनसन-पिंट

यदि आप "10:00 बजे कुछ करते हैं" जैसे अलार्म स्टोर करना चाहते हैं, तो आप इसे डीटीसी शिफ्ट्स के कारण, यूटीसी में स्टोर नहीं कर सकते। आपको इसे स्थानीय समय के सापेक्ष स्टोर करना होगा।

— एलेक्स

Answer 25

कंप्यूटर चैनल पर YouTube पर टाइमज़ोन के बारे में टॉम स्कॉट के वीडियो में विषय का एक अच्छा और मनोरंजक विवरण भी है। उदाहरणों में शामिल:

• समोआ (प्रशांत महासागर में एक द्वीप) ऑस्ट्रेलिया और न्यूजीलैंड के साथ व्यापार को आसान बनाने के लिए अपने समय क्षेत्र को 24 घंटे आगे बढ़ा रहा है,
• वेस्ट बैंक , जहां 2 लोगों की आबादी अलग-अलग समय क्षेत्रों का अनुसरण कर रही है,
• जूलियन कैलेंडर से ग्रेगोरियन कैलेंडर (जो रूस में 20 वीं शताब्दी में हुआ था) में 18 वीं शताब्दी में परिवर्तन हुआ।

Answer 26

वास्तव में, kernel32.dll SystemTimeToTzSpecificLocation निर्यात नहीं करता है। हालांकि यह निम्नलिखित दो निर्यात करता है: SystemTimeToTzSpecificLocalTime और TzSpecificLocalTimeToSystemTime ...

Answer 27

कभी भी केवल कंस्ट्रक्टरों पर निर्भर न रहें

 new DateTime(int year, int month, int day, int hour, int minute, TimeZone timezone)

वे अपवादों को फेंक सकते हैं जब डीएसटी के कारण एक निश्चित तिथि समय मौजूद नहीं होता है। इसके बजाय, ऐसी तिथियां बनाने के लिए अपने स्वयं के तरीकों का निर्माण करें। उनमें, डीएसटी के कारण होने वाले किसी भी अपवाद को पकड़ते हैं, और संक्रमण ऑफसेट के साथ समय को समायोजित करने की आवश्यकता होती है। समय के अनुसार अलग-अलग तिथियों और अलग-अलग घंटों (यहां तक ​​कि ब्राजील के लिए आधी रात को) पर डीएसटी हो सकता है।

Answer 28

केवल एक उदाहरण यह साबित करने के लिए कि समय को संभालना बहुत बड़ी गड़बड़ है, और यह कि आप कभी भी शालीन नहीं हो सकते। इस पृष्ठ पर कई स्थानों में लीप-सेकंड की अनदेखी की गई है।

कई साल पहले, एंड्रॉइड ऑपरेटिंग सिस्टम ने यूटीसी समय संदर्भ प्राप्त करने के लिए जीपीएस उपग्रहों का उपयोग किया था, लेकिन इस तथ्य को नजरअंदाज कर दिया कि जीपीएस उपग्रह छलांग-सेकंड का उपयोग नहीं करते हैं। नए साल की पूर्व संध्या पर भ्रम होने तक किसी ने ध्यान नहीं दिया, जब ऐप्पल फोन उपयोगकर्ताओं और एंड्रॉइड फोन उपयोगकर्ताओं ने लगभग 15% अलग-अलग गणना की।

मुझे लगता है कि यह तब से तय हो गया है, लेकिन आप कभी नहीं जानते कि ये 'मामूली विवरण' कब आपको परेशान करेंगे।

Answer 29

• कभी भी, कभी भी अपने UTC ऑफसेट (या समय क्षेत्र का संदर्भ) के बिना स्थानीय समय को संग्रहीत न करें- यह कैसे न करें FAT32 और struct tmC. time में।
• समझें कि एक समय क्षेत्र का एक संयोजन है
  • UTC ऑफसेट का एक सेट (जैसे सर्दियों में +0100, गर्मियों में +0200)
  • स्विचओवर होने पर नियम (जो समय के साथ बदल सकते हैं: उदाहरण के लिए, 1990 के दशक में यूरोपीय संघ ने स्विचओवर को मार्च और अक्टूबर में अंतिम रविवार को 02:00 मानक समय / 03: 00 डीएसटी पर बताया, इससे पहले यह भिन्न था; सदस्य राज्यों के बीच)।

---

Offset कुछ कार्यान्वयन struct tmयूटीसी ऑफसेट को स्टोर करते हैं, लेकिन इसने इसे मानक में नहीं बनाया है।

Answer 30

डेटाबेस के साथ काम करने में (विशेष रूप से MySQL , लेकिन यह अधिकांश डेटाबेस पर लागू होता है), मुझे यूटीसी स्टोर करना मुश्किल लगा।

• डेटाबेस आमतौर पर डिफ़ॉल्ट रूप से सर्वर डेटटाइम के साथ काम करते हैं (जो कि CURRENT_TIMESTAMP है)।
• आप सर्वर टाइमज़ोन को बदलने में सक्षम नहीं हो सकते हैं।
• यहां तक ​​कि अगर आप टाइमज़ोन को बदलने में सक्षम हैं, तो आपके पास थर्ड-पार्टी कोड हो सकता है जो सर्वर टाइमज़ोन को स्थानीय होने की उम्मीद करता है।

मुझे डेटाबेस में सर्वर डेटाइम को स्टोर करना आसान लगा, फिर डेटाबेस को संग्रहीत विवरणों को UTC (यानी UNIX_TIMESTAMP ()) में SQL स्टेटमेंट में कनवर्ट करने दें। उसके बाद आप अपने कोड में UTC के रूप में डेटाटाइम का उपयोग कर सकते हैं।

यदि आपके पास सर्वर और सभी कोड पर 100% नियंत्रण है, तो संभवतः सर्वर टाइमज़ोन को यूटीसी में बदलना बेहतर है।

Comments

स्थानीय समय (सर्वर का समय) "फॉल-बैक" स्टाइल डेलाइट बचत संक्रमण के दौरान अस्पष्ट हो सकता है। जैसा कि आपने वर्णित किया, इसका उपयोग करना विश्वसनीय नहीं है। एक से अधिक यूटीसी समय हो सकता है जो सर्वर के स्थानीय समय का प्रतिनिधित्व कर सकता है।

— मैट जॉनसन-पिंट

स्थानीय समय पूरी तरह से ठीक है अगर सर्वर एक समय क्षेत्र में स्थित है, यानी वह जो डीएसटी नहीं करता है।

— Sayap