अलग-अलग समय क्षेत्रों में समय के साथ काम करने की विशेषताएं

इस तथ्य के कारण कि समय के साथ काम करने पर कई सवाल और निर्णय जमा हो गए हैं, मैंने एक छोटी समीक्षा करने का फैसला किया।

डेटाबेस में विभिन्न प्रकार के डेटा के साथ काम करें

MYSQL

समय का प्रतिनिधित्व करने के लिए mysql में कई मानक डेटा प्रकार हैं; हम TIMESTAMP और DATETIME को देखेंगे।
दस्तावेज़ कहता है कि रूपांतरण नीति कुछ प्रकार के डेटा पर लागू होती है, लेकिन कुछ के लिए नहीं।
व्यवहार में, सब कुछ बहुत अधिक दिलचस्प है। आइए कुछ उदाहरण देखें:
एक तालिका बनाएँ:

 create table xxxDate(ts TIMESTAMP NOT NULL, dt DATETIME NOT NULL); 

हम मास्को के लिए वर्तमान क्षेत्र निर्धारित करेंगे (मास्को में हाल ही में कोई डेलाइट सेविंग टाइम नहीं है, और UTC + 4):

 set time_zone='Europe/Moscow'; 

क्रमशः गर्मियों और सर्दियों के समय के साथ दो रिकॉर्ड बनाएं:

 insert into xxxDate values('2012-06-10 15:08:05', '2012-06-10 15:08:05'); insert into xxxDate values('2012-12-10 15:08:05', '2012-12-10 15:08:05'); 

आइए देखें कि डेटाबेस से इन तारीखों का चयन क्या दर्शाता है:

 select * from xxxDate; +---------------------+---------------------+ | ts | dt | +---------------------+---------------------+ | 2012-06-10 15:08:05 | 2012-06-10 15:08:05 | | 2012-12-10 15:08:05 | 2012-12-10 15:08:05 | +---------------------+---------------------+ select UNIX_TIMESTAMP(ts), UNIX_TIMESTAMP(dt) from xxxDate; +--------------------+--------------------+ | UNIX_TIMESTAMP(ts) | UNIX_TIMESTAMP(dt) | +--------------------+--------------------+ | 1339326485 | 1339326485 | | 1355137685 | 1355137685 | +--------------------+--------------------+ 

हम देखते हैं कि दोनों स्तंभों में मान समान हैं, ऐसा इसलिए है क्योंकि UNIX_TIMESTAMP फ़ंक्शन वर्तमान ज़ोन में तर्क के मूल्य पर विचार करता है और इसे UTC में रूपांतरित करता है। जाहिर है, समान मान समान रूप से एक ही मान में परिवर्तित होते हैं Mon, 10 Dec 2012 11:08:05 UTC ।
अब हम लंदन जा रहे हैं!

 set time_zone='Europe/London'; select * from xxxDate; +---------------------+---------------------+ | ts | dt | +---------------------+---------------------+ | 2012-06-10 12:08:05 | 2012-06-10 15:08:05 | | 2012-12-10 11:08:05 | 2012-12-10 15:08:05 | +---------------------+---------------------+ 

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

 select UNIX_TIMESTAMP(ts), UNIX_TIMESTAMP(dt) from xxxDate; +--------------------+--------------------+ | UNIX_TIMESTAMP(ts) | UNIX_TIMESTAMP(dt) | +--------------------+--------------------+ | 1339326485 | 1339337285 | // 14h (dt) | 1355137685 | 1355152085 | // 15h (dt) +--------------------+--------------------+ 

Ts मान नहीं बदले हैं, और dt मान को वर्तमान क्षेत्र में मान के रूप में माना जाता है, इसलिए, गर्मी का समय (पहला रिकॉर्ड) 1339337285 = Sun, 10 Jun 2012 14:08:05 GMT और सर्दियों का समय (निचला रिकॉर्ड) 1355152085 = Mon, 10 Dec 2012 15:08:05 GMT ।
बस मामले में, यूटीसी के लिए व्यवहार की जांच करें।

 set time_zone='UTC'; select * from xxxDate; +---------------------+---------------------+ | ts | dt | +---------------------+---------------------+ | 2012-06-10 11:08:05 | 2012-06-10 15:08:05 | | 2012-12-10 11:08:05 | 2012-12-10 15:08:05 | +---------------------+---------------------+ select UNIX_TIMESTAMP(ts), UNIX_TIMESTAMP(dt) from xxxDate; +--------------------+--------------------+ | UNIX_TIMESTAMP(ts) | UNIX_TIMESTAMP(dt) | +--------------------+--------------------+ | 1339326485 | 1339340885 | // 15h (dt) | 1355137685 | 1355152085 | // 15h (dt) +--------------------+--------------------+ 

सब कुछ पिछले विवरण के अनुसार है, ts मान नहीं बदले हैं, dt मान वर्तमान क्षेत्र में माना जाता है, इसलिए वे भी नहीं बदलते हैं ( 1339340885 = Sun, 10 Jun 2012 15:08:05 GMT; 1355152085 = Mon, 10 Dec 2012 15:08:05 GMT ); ।
निष्कर्ष:

• DATETIME साथ काम करते समय और सर्वर / कनेक्शन समय क्षेत्र बदलने के समय की जानकारी के नुकसान के साथ सर्वर (डेटा प्रविष्टि या आयात के दौरान गलत टाइम ज़ोन सेटिंग) को आगे बढ़ाते हुए, आप घटनाओं के वास्तविक समय के बारे में जानकारी खो देंगे। उदाहरण के लिए, हमने 15:00 मास्को समय में रिकॉर्ड बनाया (हमने बैकअप से डेटाबेस में डेटा आयात किया), फिर यूटीसी पर अपना सर्वर स्थापित किया और यह नहीं देखा कि इससे पहले समय क्षेत्र मास्को था। परिणामस्वरूप, 11 घंटे UTC के बजाय, हमारे दोनों आदेश अब 4 घंटे बाद - 15 घंटे पर बने हैं, और एक और दिन हो सकता है। इसलिए, मेरी राय में, आपको TIMESTAMP साथ काम करने की आवश्यकता है।
• इसके अलावा, सर्वर पर डिबगिंग करते समय अनावश्यक समस्याओं से बचने के लिए, यूटीसी ज़ोन का होना बेहतर है और यूटीसी में डेटा के साथ काम करना है, और क्लाइंट की तरफ, उस क्षेत्र में प्रदर्शित करें जिसमें क्लाइंट चाहता है।
• फीडबी लेख के अंत में एक अच्छा उदाहरण भी।
• लीप सेकंड के साथ समस्याओं से बचने के लिए यह यूटीसी में यूनिक्स युगों के साथ काम करने लायक भी है (लीप सेकंड पर अनुभाग देखें)।

SQLite3

Sqlite3 के साथ स्थिति पर विचार करें। Sqlite में प्रलेखन के अनुसार, समय की बचत के लिए कोई डेटा प्रकार नहीं है, लेकिन पाठ के रूप में संग्रहीत समय, एक फ्लोटिंग-पॉइंट नंबर और पूर्णांक के रूप में कार्य करने के लिए कार्य हैं। सामान्य तौर पर, ये विचार मूल रूप से अलग नहीं होते हैं। हम मान सकते हैं कि यदि आप स्थानीय समय और utc संशोधक का उपयोग नहीं करते हैं तो sqlite में वर्तमान समय क्षेत्र का उपयोग नहीं किया जाता है। उदाहरण के लिए, सिस्टम सेटिंग्स की परवाह किए बिना, CURRENT_TIMESTAMP UTC पर सेट है।

 $ date Mon Dec 10 22:05:50 MSK 2012 $ sqlite3 sqlite> select CURRENT_TIMESTAMP; 2012-12-10 18:06:05 sqlite> select datetime(CURRENT_TIMESTAMP, 'localtime'); 2012-12-10 22:06:35 

इसलिए, अपने डेटा को अपने प्रोग्राम में यूनिक्स और यूनिक युग का उपयोग करने के लिए परिवर्तित करें ताकि स्ट्रिंग को पार्स करते समय त्रुटियों की तलाश न करें।
डिबगिंग के लिए कार्य:

 select strftime('%s', CURRENT_TIMESTAMP); 1355162582 select datetime(1355152085, 'unixepoch'); 2012-12-10 15:08:05 

उपयोगकर्ता समय कैसे देखता है

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

समय के साथ काम करने के लिए सी-फ़ंक्शंस

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

 Function: struct tm * localtime_r(const time_t *time, struct tm *resultp) 

उपयोगकर्ता ज़ोन के सापेक्ष व्यक्त किए गए टूटे-फूटे समय को सरल समय देता है।

  time_t t = 1339326485; // 2012-06-10 11:08:05 (UTC) struct tm bdt; localtime_r (&t, &bdt); cout << bdt.tm_hour << endl; cout << bdt.tm_isdst << endl; cout << bdt.tm_zone << endl; 

सिस्टम में ज़ोन	यूटीसी	यूरोप / मास्को	यूरोप / लंदन
घंटे का उत्पादन	11	15	12
isdst आउटपुट	0	0	1
ज़ोन आउटपुट	यूटीसी	एमएसके	BST

  time_t t = 1355137685; // 2012-12-10 11:08:05 (UTC) 

सिस्टम में ज़ोन	यूटीसी	यूरोप / मास्को	यूरोप / लंदन
घंटे का उत्पादन	11	15	11
isdst आउटपुट	0	0	0
ज़ोन आउटपुट	यूटीसी	एमएसके	जीएमटी

 Function: struct tm * gmtime_r(const time_t *time, struct tm *resultp) 

उपयोगकर्ता क्षेत्र की परवाह किए बिना UTC क्षेत्र के लिए मान लौटाता है।

  time_t t = 1339326485; // 2012-06-10 11:08:05 (UTC) struct tm bdt; gmtime_r (&t, &bdt); cout << bdt.tm_hour << endl; cout << bdt.tm_isdst << endl; cout << bdt.tm_zone << endl; 

सिस्टम में ज़ोन	यूटीसी	यूरोप / मास्को	यूरोप / लंदन
घंटे का उत्पादन	11	11	11
isdst आउटपुट	0	0	0
ज़ोन आउटपुट	जीएमटी	जीएमटी	जीएमटी

  time_t t = 1355137685; // 2012-12-10 11:08:05 (UTC) 

सिस्टम में ज़ोन	यूटीसी	यूरोप / मास्को	यूरोप / लंदन
घंटे का उत्पादन	11	11	11
isdst आउटपुट	0	0	0
ज़ोन आउटपुट	जीएमटी	जीएमटी	जीएमटी

 Function: time_t mktime(struct tm *brokentime) 

( समयबद्धता का पर्यायवाची, लेकिन दुर्लभ)
टूटे-फूटे समय को सरल समय में परिवर्तित करता है।
ध्यान: तर्क के लिए वर्तमान क्षेत्र सेट करता है।
Tm_zone फ़ील्ड को एक तर्क के रूप में नहीं माना जाता है, यह माना जाता है कि समय वर्तमान समय क्षेत्र में सेट किया गया है और यूटीसी में समय वापस आ गया है।

  struct tm bdt; bdt.tm_sec = 5; // 05 sec bdt.tm_min = 8; // 08 min bdt.tm_hour = 11; // 11 h bdt.tm_mday = 10; // 10 bdt.tm_mon = 5; // 6th mon - Jun bdt.tm_year = 112;// 2012 - 1900 bdt.tm_wday = 0; // ignored bdt.tm_yday = 0; // ignored bdt.tm_isdst= 0; bdt.tm_gmtoff= 0; bdt.tm_zone = "UTC"; time_t t = mktime(&bdt); cout << t << endl; cout << bdt.tm_hour << endl; cout << bdt.tm_isdst << endl; cout << bdt.tm_gmtoff << endl; cout << bdt.tm_zone << endl; 

सिस्टम में ज़ोन	यूटीसी	यूरोप / मास्को	यूरोप / लंदन
पिन टी	1339326485 (सूर्य, 10 जून 2012 11:08:05 GMT)	1339312085 (सूर्य, 10 जून 2012 07:08:05 GMT)	1339326485 (सूर्य, 10 जून 2012 11:08:05 GMT)
घंटे का उत्पादन	11	11	12
isdst आउटपुट	0	0	1
gmtoff आउटपुट	0	14400 (4 * 60 * 60)	3600 (1 * 60 * 60)
ज़ोन आउटपुट	यूटीसी	एमएसके	BST

कृपया ध्यान दें कि tm_hour और tm_isdst फ़ील्ड लंदन के लिए बदल गए हैं, यह टूट-डाउन टाइम संरचना के क्षेत्रों को सामान्य करने की प्रक्रिया का हिस्सा है।
अब के लिए

 bdt.tm_mon = 11; // 11th mon - Dec 

सिस्टम में ज़ोन	यूटीसी	यूरोप / मास्को	यूरोप / लंदन
पिन टी	1355137685 (सोम, 10 दिसंबर 2012 11:08:05 GMT)	1355123285 (सोम, 10 दिसंबर 2012 07:08:05 GMT)	1355137685 (सोम, 10 दिसंबर 2012 11:08:05 GMT)
घंटे का उत्पादन	11	11	11
isdst आउटपुट	0	0	0
gmtoff आउटपुट	0	14400 (4 * 60 * 60)	0
ज़ोन आउटपुट	यूटीसी	एमएसके	जीएमटी

 Function: time_t timegm(struct tm *brokentime) 

यह यूटीसी में काम करता है।

सिस्टम में ज़ोन	यूटीसी	यूरोप / मास्को	यूरोप / लंदन
पिन टी	1339326485 (सूर्य, 10 जून 2012 11:08:05 GMT)	1339326485 (सूर्य, 10 जून 2012 11:08:05 GMT)	1339326485 (सूर्य, 10 जून 2012 11:08:05 GMT)
घंटे का उत्पादन	11	11	11
isdst आउटपुट	0	0	0
gmtoff आउटपुट	0	0	0
ज़ोन आउटपुट	जीएमटी	जीएमटी	जीएमटी

अब के लिए

 bdt.tm_mon = 11; // 11th mon - Dec 

सिस्टम में ज़ोन	यूटीसी	यूरोप / मास्को	यूरोप / लंदन
पिन टी	1355137685 (सोम, 10 दिसंबर 2012 11:08:05 GMT)	1355137685 (सोम, 10 दिसंबर 2012 11:08:05 GMT)	1355137685 (सोम, 10 दिसंबर 2012 11:08:05 GMT)
घंटे का उत्पादन	11	11	11
isdst आउटपुट	0	0	0
gmtoff आउटपुट	0	0	0
ज़ोन आउटपुट	जीएमटी	जीएमटी	जीएमटी

निष्कर्ष:
यदि आप उपयोगकर्ता कंप्यूटर पर अपने प्रोग्राम में उपयोगकर्ता को समय प्रदर्शित करना चाहते हैं, तो timelocal/localtime फ़ंक्शन का उपयोग करें, यदि आप सर्वर पर काम कर रहे हैं, तो timegm/gmtime उपयोग करें। इसके अलावा, सर्वर पर UTC ज़ोन सेट करें, यदि आपका कोई सहकर्मी या किसी तृतीय-पक्ष लाइब्रेरी में * स्थानीय * फ़ंक्शंस का उपयोग करता है। यहां तक ​​कि उपयोगकर्ता के कंप्यूटर पर, यूटीसी में समय के साथ स्टोर और काम करते हैं, इसलिए यदि वह अपना क्षेत्र बदलता है, तो सभी तिथियां सही रहेंगी।

टिप्पणी

लिनक्स में समय क्षेत्र निर्धारित करना

समय क्षेत्र की स्थापना के लिए केवल बहस-आधारित वितरण और लोहे के तरीकों की एक जोड़ी पर विचार करें।

• विधि एक (डिबेट-आधारित वितरण पर काम करता है):
  टर्मिनल में एक कमांड चलाएं और निर्देशों का पालन करें ("UTC" "Etc" सेक्शन में है):
  sudo dpkg-reconfigure tzdata
• दूसरा तरीका (यह काम करता है, शायद हर जगह):
  टर्मिनल में कमांड चलाएँ:
  

   sudo ln -sf /usr/share/zoneinfo/UTC /etc/localtime 

  
  और बस मामले में, संपादित करें /etc/timezone (यदि कोई हो)
• तीसरा तरीका:
  उदाहरण के लिए इच्छित परिवेश के लिए टीबी वातावरण चर सेट करें:
  

   export TZ=Europe/London 

LEAP सेकंड

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

• UTC में लीप सेकंड शामिल है
• बहुत महत्वपूर्ण नोट :
  POSIX की आवश्यकता है कि 1 जनवरी, 1970 को 00:00:00 बजे से गिने जाने वाले समय_ को UTC में लीप सेकंड शामिल नहीं किया जाता है, लेकिन व्यवहार में कभी-कभी ऐसा होता है। इसके अलावा, लीप सेकेंड सपोर्ट के आधार पर, डिफ़ेक्टटाइम फ़ंक्शन अलग तरीके से काम करता है। सावधान रहें।
• जूलियन डे में लीप सेकेंड भी शामिल नहीं है।
• Mysql में आप लीप सेकेंड नहीं देखेंगे, अर्थात 60 या 61 सेकंड के बजाय हमेशा 59 ( लिंक ) होगा। लेकिन एक ही समय में, सब कुछ समर्थित है और सही ढंग से काम करता है यदि आप यूटीसी में यूनिक्स युगों से निपट रहे हैं।
• Sqlite के लिए सामान्य अनुशंसा: दिनांक को पूर्णांक के रूप में संग्रहीत करें, जिसमें पहले से ही लीप सेकंड (mysql के रूप में) शामिल हैं। तब आपको हमेशा सही समय का पता चल जाएगा।

और अधिक

• यदि time_zone (mysql) चर का मान SYSTEM है, तो सिस्टम ज़ोन (जो उस समय सिस्टम में कॉन्फ़िगर किया गया था जब सर्वर शुरू हुआ था) को वर्तमान ज़ोन के रूप में चुना गया है।
• http://www.onlineconversion.com/unix_time.htm साइट को यूनिक्स को सामान्य समय में परिवर्तित करने के लिए
• GMT - एक पुरानी अवधारणा के रूप में माना जा सकता है, इसलिए, लेख मुख्य रूप से UTC का उपयोग करता है।