मैं हमेशा सब कुछ के लिए यूनिक्स टाइमस्टैम्प का उपयोग करता हूं, लेकिन सोच रहा हूं कि कोई बेहतर तरीका है या नहीं।यूनिक्स टाइमस्टैम्प टाइमस्टैम्प स्टोर करने का सबसे अच्छा तरीका है?
टाइमस्टैम्प स्टोर करने के लिए आप क्या उपयोग करते हैं और क्यों?
हालांकि आप एक टाइमस्टैम्प स्टोर करना चुनते हैं, क्षेत्रीय व्याख्या समस्याओं और समय ऑफसेट समस्याओं से बचना महत्वपूर्ण है। एक यूनिक्स टाइमस्टैम्प को क्षेत्र के बावजूद समान व्याख्या की जाती है, और समय क्षेत्र के बावजूद उसी बिंदु से गणना की जाती है - ये अच्छी चीजें हैं।
01/02/2008 जैसे संदिग्ध तारों के रूप में टाइमस्टैम्प संग्रहीत करने से सावधान रहें, क्योंकि इसे लोकेल के आधार पर 02 जनवरी, 2008 या 01 फरवरी, 2008 के रूप में व्याख्या किया जा सकता है।
घंटे/मिनट/सेकंड संग्रहीत करते समय, यह जानना महत्वपूर्ण है कि "कौन सा" घंटा/मिनट/सेकंड निर्दिष्ट किया जा रहा है। आप टाइमज़ोन जानकारी समेत ऐसा कर सकते हैं (यूनिक्स टाइमस्टैम्प के लिए आवश्यक नहीं है, क्योंकि इसे यूटीसी माना जाता है)।
हालांकि, ध्यान दें कि यूनिक्स टाइमस्टैम्प समय पर कुछ इंस्टेंट्स का विशिष्ट रूप से प्रतिनिधित्व नहीं कर सकता है: जब यूटीसी में एक लीप दूसरा होता है, तो यूनिक्स टाइमस्टैम्प नहीं बदलता है, इसलिए अगले 23:59:60 यूटीसी और 00:00:00 दोनों दिन एक ही यूनिक्स प्रतिनिधित्व है। तो यदि आपको वास्तव में एक सेकंड या बेहतर रिज़ॉल्यूशन की आवश्यकता है, तो एक और प्रारूप पर विचार करें।
यदि आप यूनिक्स टाइमस्टैम्प की तुलना में स्टोरेज के लिए अधिक मानव पठनीय प्रारूप पसंद करते हैं, तो ISO 8601 पर विचार करें।
एक तकनीक जो चीजों को सीधे आगे बढ़ाने में मदद करती है वह यूटीसी के रूप में तारीखों को स्टोर करना है और उपयोगकर्ता को दिनांक प्रदर्शित करते समय केवल समय क्षेत्र या डीएसटी ऑफ़सेट लागू करना है।
32 bit Unix timestamps will overflow in a few years (January 2038), ताकि यह एक विचार हो। मैं आमतौर पर एसक्यूएल में एक डेटाटाइम प्रारूप का उपयोग करता हूं, जो वाई वाई वाई वाई-एमएम-डीडी एचएच: एमएम: एसएस 24 घंटे की घड़ी के रूप में समय के साथ है। मैं अपने जीवन को आसान बनाने के लिए, उसी प्रारूप में फ़ाइलों को आउटपुट करने का प्रयास करता हूं।
आपको किस स्टोर को स्टोर करने की आवश्यकता है और किस संकल्प के लिए? यदि आपको माइक्रोसेकंड की आवश्यकता है, या पत्थर युग में दिनांक समय_t सबसे अच्छा नहीं हो सकता है। सामान्य व्यापार उद्देश्यों के लिए यह काफी अच्छा है (64 बिट मानते हुए)
उन्होंने पाषाण युग में _have_ तिथियां नहीं कीं, क्या उन्होंने? –
निश्चित रूप से उन्होंने किया - आप एक अच्छी लड़की से मिलते हैं, उसे सिर पर ले जाते हैं और उसे वापस अपनी गुफा में खींचते हैं - बहुत रोमांटिक .... –
आपको खगोलीय घटनाओं (ग्रहण इत्यादि जैसी चीजों के लिए लंबी अवधि में दिनांक/समय की गणना करने की आवश्यकता है।) इस के लिए सिस्टम (जूलियन दिन) लगभग 5000bc –
समय-शैली (time_t + microseconds) यदि मुझे उप-सेकंड सटीकता की आवश्यकता है, तो बस time_t। आप time_t * 1000000 + usec को स्टोर करने के लिए 64-बिट पूर्णांक मान का उपयोग कर सकते हैं और आप +/- 2 9 2,000 वर्षों से अधिक के लिए ओवरफ़्लो-सबूत हैं।
यह एक बहुत अच्छा विचार है। –
एक टाइमस्टैम्प bascially है:
और कुछ ही समय में एक बिंदु के रूप में एक विशिष्ट बिंदु एक अंतहीन संकल्प, एक टाइमस्टैम्प प्रारूप चुनने पर महत्वपूर्ण बात यह है: यह काफी है संकल्प?
सबसे अनुप्रयोगों मैं था के लिए है, नैनोसेकंड पर्याप्त थे। तो जावा टाइमस्टैम्प के पास अब तक मेरे लिए सही संकल्प था।
यह इस बात पर निर्भर करता है कि आपको किस टाइमस्टैम्प की आवश्यकता है।
एक यूनिक्स टाइमस्टैम्प 2008-12-31T23: 59: 59Z के बाद 1 सेकंड का प्रतिनिधित्व नहीं कर सकता है। यदि आप '200 9-01-01T09: 00: 00' - '2008-12-31T09: 00: 00' यूनिक्स टाइमस्टैम्प के साथ परिणाम सही नहीं है: उन दो तिथियों के बीच एक छलांग दूसरा होगा और वे 86401 सेकेंड से अलग (86400 नहीं, यूनिक्स टाइमस्टैम्प आपको बताएंगे)।
उसके अलावा और क्या अन्य प्रतिसाददाताओं कहा, हां - यूनिक्स टाइमस्टैम्प जाने का रास्ता हैं :)
एक टाइमस्टैम्प, डेटाबेस पर एक अच्छा विचार नहीं है, क्योंकि वे दिन के उजाले बचत या चालू नहीं लेते खाते में स्थानीय समय। MySQL पर इसे एक समय के रूप में स्टोर करना बेहतर होता है, और उसके बाद इच्छित हिस्सों को पुनः प्राप्त करने के लिए MySQL date and time functions का उपयोग करें, या अन्य तिथियों की तुलना करें।
यदि आप लॉग फ़ाइल संग्रहित कर रहे हैं, तो कृपया पेटी के प्यार के लिए इसे मानव पठनीय और व्याख्यात्मक-क्रमबद्ध बनाएं।
2008-10-07 09:47:02 उदाहरण के लिए।
7 साल ... मानव पठनीय महान है और मैं इसके लिए सब कुछ हूं लेकिन इस उदाहरण की तारीख संदिग्ध है। यदि आपको वास्तव में कुछ पता होना चाहिए कि आपको कुछ समय क्षेत्र की जानकारी चाहिए तो 2008-10-07T09: 47: 02Z जैसे कुछ के साथ जाएं ताकि आपको मानव पठनीयता और समय पर एक सटीक बिंदु मिल सके। –
यह संदिग्ध नहीं है। कोई नहीं है ????? ?? - ??'दिनांक प्रारूप जो' yyyy-mm-dd' नहीं है, यानी "टी" को छोड़कर आईएसओ -8601। –
मुझे पसंद है कि पोस्ट बटन पर क्लिक करने में आपको एक मिनट का समय लगेगा – Samus
यूनिक्स टाइमस्टैम्प 32-बिट समस्या 2038+ में भविष्य की तिथियों में प्रवेश करने वाले उपयोगकर्ताओं के लिए बहुत परेशान प्रतीत होती है।
या तो MySQL के लिए DATETIME अनुक्रम का उपयोग करें, या अपनी तिथियों को बिगिनट (8) हस्ताक्षरित (अधिकतम: 18 क्विंटलियन) या फ़्लोट के रूप में संग्रहीत करें ताकि आप बड़ी संख्या में प्रवेश कर सकें। फिर आप उदाहरण के लिए PHP की दिनांक() फ़ंक्शन का उपयोग नहीं कर सकते क्योंकि यह केवल पूर्णांक को पैरामीटर के रूप में अनुमति देता है (32-बिट सिस्टम द्वारा सीमित)।
मुझे मिला समाधानPHP 5.2.0 फ़ंक्शंस का उपयोग करना है। Here's the DateTime PHP solution।
UNIX_TIMESTAMP प्रारूप को बदलने की कोई आवश्यकता नहीं है। जब तक आपके पास बिगिनट (8) टाइमस्टैम्प के लिए आपके MySQL स्टोरेज के रूप में हस्ताक्षरित है। अब आप 32-बिट सिस्टम तक सीमित नहीं होंगे।
2038 32 बिट के लिए लेकिन अधिकांश सिस्टम अब 64 बिट हैं –
यह 2038 है - http://en.wikipedia.org/wiki/Year_2038_problem – warren
फिक्स्ड और लिंक। @ एमजीबी - हाँ, हालांकि मुझे लगता है कि एम्बेडेड सिस्टम में सबसे अधिक परेशानी होगी। –