2013-08-07 6 views
5

मुझे कुछ टाइमस्टैम्प फ़ील्ड को हमारे MySQL (InnoDB) डीबी में INT में कनवर्ट करने की आवश्यकता है। मुझे एहसास है कि TIMESTAMP को INT में परिवर्तित करना असामान्य है, लेकिन हमें अभी भी इसे करने की आवश्यकता है :)माइस्क्ल टाइमस्टैम्प को INTEGER में परिवर्तित कर रहा है - टाइमज़ोन

ऐसा लगता है कि ऐसा करने के लिए पर्याप्त आगे है, लेकिन कुछ टाइमज़ोन और डेलाइट सेविंग त्रुटियां हैं।

मेरे पास एक स्क्रिप्ट है जो प्रति कॉलम मेरे SQL कोड उत्पन्न करती है। उदाहरण के लिए, यह उत्पन्न करता है:

ALTER TABLE alarmLog ADD COLUMN started_tmp INT UNSIGNED; 
UPDATE alarmLog SET started_tmp = UNIX_TIMESTAMP(started); 
ALTER TABLE alarmLog DROP started; 
alter TABLE alarmLog CHANGE started_tmp started INT UNSIGNED NULL DEFAULT 0; 

अगर मैं पहले और select FROM_UNIXTIME(1291788036); का उपयोग कर, परिणाम अच्छा लग रहा है डेटा के बाद की तुलना करें।

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

लेकिन तब डॉक्स warn me इस परिदृश्य के बारे में (सीईटी में डेलाइट सेविंग):

mysql> SELECT UNIX_TIMESTAMP('2005-03-27 02:00:00'); 
+---------------------------------------+ 
| UNIX_TIMESTAMP('2005-03-27 02:00:00') | 
+---------------------------------------+ 
|       1111885200 | 
+---------------------------------------+ 
1 row in set (0.00 sec) 

mysql> SELECT UNIX_TIMESTAMP('2005-03-27 03:00:00'); 
+---------------------------------------+ 
| UNIX_TIMESTAMP('2005-03-27 03:00:00') | 
+---------------------------------------+ 
|       1111885200 | 
+---------------------------------------+ 
1 row in set (0.00 sec) 

कैसे एपीआई और ओएस सामान्य रूप से डेलाइट सेविंग के साथ सौदा करते हैं? मुझे पता है कि मेरे पीसी की यूटीसी में घड़ी है और गर्मी के समय में, ओएस इसमें दो घंटे जोड़ता है, और सर्दियों के समय में एक। मुझे लगता है कि यह निर्धारित करने के लिए यूटीसी समय का उपयोग करता है कि यह डीएसटी है या नहीं।

तो, मैं इससे कैसे निपटूं? डीएसटी ऑफसेट निर्दिष्ट करने के लिए डेटाबेस में फ़ील्ड जोड़ने का एकमात्र समाधान है?

+1

ग्रीष्मकालीन समय एक अलग समय क्षेत्र है। जैसे सीईटी केंद्रीय यूरोपीय समय है, सीईएसटी मध्य यूरोपीय ग्रीष्मकालीन समय है। आपका ओएस कब स्विच करना जानता है। जब तक आप टाइमस्टैम्प के लिए यूटीसी का उपयोग करते हैं, तब तक यह स्थानीय समय में कनवर्ट करने के लिए प्रस्तुति परत पर निर्भर करता है। –

उत्तर

3

आपको आईएनटी में समय स्टोर करने की आवश्यकता नहीं है। MySQL का TIMESTAMP प्रकार वैसे भी करता है (यह समय को संग्रहीत करने के लिए मानक यूनिक्स टाइमस्टैम्प का उपयोग करता है) और वे हमेशा यूटीसी में रहते हैं।

आपको केवल सत्र टाइमज़ोन सेट करने की आवश्यकता है और जब आप अपडेट/चुनते हैं तो सभी टाइमस्टैम्प कॉलम आपके क्षेत्र से/आपके क्षेत्र में परिवर्तित हो जाएंगे।

आप कनेक्ट/प्रारंभ समय एक बार में क्षेत्र सेट कर सकते हैं:

SET time_zone = '+10:00'; 

और फिर आपके द्वारा चुने गए/अपने क्षेत्र में समय अद्यतन कर सकते हैं सीधे

SELECT timesamp_column FROM table ... 

मैं से परिचित नहीं हूँ डेटाटाइम libs लेकिन मुझे लगता है कि वे आपके द्वारा प्रदान किए गए टाइमज़ोन और टाइमज़ोन और डेलाइट सेविंग ऑफसेट निर्धारित करने के लिए प्रश्न में समय का उपयोग करते हैं।

आपके द्वारा प्रदान किए गए उदाहरण में मुझे लगता है कि मानों में से एक वास्तव में अमान्य है, क्योंकि घड़ी 01:59:59 से 03:00:00 और 02:00:00 तक कूदने का अनुमान है वास्तव में कभी नहीं हुआ। UNIX_TIMESTAMP फ़ंक्शन शायद उस मामले में निकटतम दूसरा लौटाता है।

+0

मुझे पता है कि मैं टाइमस्टैम्प का उपयोग कर सकता हूं, लेकिन मैं उस प्रकार का उपयोग नहीं कर सकता। क्लाइंट-साइड को स्क्लाइट के साथ संगत होने की आवश्यकता है, इसलिए आईएनटी में रूपांतरण। और अमान्य समय के बारे में; डेलाइट के अंत में आप दिन में दो बार एक निश्चित समय बचाते हैं, जो एक ही समस्या होगी। – Halfgaar

+0

उसी स्ट्रिंग प्रस्तुति के साथ समय में कई बिंदु हैं और अंतराल भी हैं। मुझे नहीं लगता कि आप इसके बारे में कुछ भी कर सकते हैं। अपने मानों को यूनिक्स टाइमस्टैम्प (आईएनटी) के रूप में स्टोर करें और उन्हें स्थानीय समय में MySQL के फ़ंक्शंस या टाइम लाइब्रेरी क्लाइंट साइड के साथ रूपांतरित करें। जब तक आप टाइमज़ोन को सही तरीके से सेट करते हैं, तब तक इसे सही तरीके से प्रदर्शित करना चाहिए। – Vatev

+0

मैंने बस TIMESTAMP कॉलम में '2005-03-27 02:00:00' डालने का परीक्षण किया। इसे पुनर्प्राप्त करने से आपको '2005-03-27 03:00:00' भी मिल जाता है, इसलिए मुझे लगता है कि यह ठीक है। – Halfgaar

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

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