माइक्रोटाइम के लिए दशमलव लंबाई (सच)?

टीएल; डॉ। माइक्रोटाइम (झूठी) का प्रयोग करें और परिणामों को लाखों सेकेंड के रूप में एक MySQL बिगिंट में स्टोर करें। अन्यथा आपको फ़्लोटिंग पॉइंट अंकगणित के बारे में सब कुछ सीखना होगा, जो एक बड़ा मोटा हेयरबॉल है।

PHP माइक्रोटाइम फ़ंक्शन एक सिस्टम कॉल से यूनिक्स टाइमस्टैम्प (वर्तमान में लगभग हेक्स 50eb7c00 या दशमलव 1,357,609,984) और दूसरे सिस्टम कॉल से माइक्रोसेकंड समय को पकड़ लेता है। यह तब उन्हें एक चरित्र स्ट्रिंग में बनाता है। फिर, यदि आप इसे (सत्य) कहते हैं, तो यह उस संख्या को 64-बिट IEEE 745 फ्लोटिंग पॉइंट नंबर में बदल देता है, जिसे PHP float कहता है। .

आज तक आपको एक पूर्णांक UNIX टाइमस्टैम्प को संग्रहीत करने के लिए दशमलव बिंदु के बाईं ओर दस दशमलव अंकों की आवश्यकता है। यह लगभग 2280 ईस्वी तक सच रहेगा जब आपके वंशजों को ग्यारह अंकों की आवश्यकता होने लगेगी। माइक्रोसेकंड स्टोर करने के लिए आपको दशमलव स्थान के दाईं ओर छह अंकों की आवश्यकता होगी।

आपको कुल माइक्रोसेकंड सटीकता नहीं मिलने वाली है। अधिकांश सिस्टम 1-33 मिलीसेकंड की सीमा में किसी चीज़ के रिज़ॉल्यूशन के साथ अपनी सब-सेकंड सिस्टम क्लॉक रखते हैं। यह सिस्टम पर निर्भर है।

MySQL संस्करण 5.6.4 और बाद में आपको DATETIME(6) specify निर्दिष्ट करने की अनुमति देता है कॉलम, जो माइक्रोसेकंड रिज़ॉल्यूशन के लिए दिनांक और समय रखेगा। यदि आप ऐसे MySQL संस्करण का उपयोग कर रहे हैं जो बिल्कुल सही है।

संस्करण 5.6.4 से पहले, आपको MySQL DOUBLE . का उपयोग करने की आवश्यकता है (आईईईई 754 64-बिट फ्लोटिंग पॉइंट) इन नंबरों को स्टोर करने के लिए। MySQL FLOAT (आईईईई 754 32-बिट फ़्लोटिंग पॉइंट) में इसके मंटिसा में पर्याप्त बिट्स नहीं हैं जो वर्तमान यूनिक्स समय को सेकंड में पूरी तरह से सटीक रूप से स्टोर कर सकते हैं।

आप इन टाइमस्टैम्प को क्यों स्टोर कर रहे हैं? क्या आप ऐसा करने की उम्मीद कर रहे हैं

  WHERE table.timestamp = 1357609984.100000

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

  WHERE table.timestamp BETWEEN 1357609984.100000 - 0.001
                            AND 1357609984.100000 + 0.001

या कुछ इसी तरह। यदि आप इन टाइमस्टैम्प को दशमलव के रूप में या सेकंड के लाखोंवें हिस्से में bigint में संग्रहीत करते हैं, तो आपको यह समस्या नहीं होगी। कॉलम।

आईईईई 64-बिट फ्लोटिंग पॉइंट में 53 बिट मंटिसा है - सटीक। वर्तमान UNIX युग टाइमस्टैम्प (1-जनवरी-1970 00:00Z के बाद से सेकंड) दस लाख बार 51 बिट्स का उपयोग करता है। इसलिए यदि हम कम-आदेश बिट की परवाह करते हैं तो डबल में बहुत अधिक सटीकता नहीं है। दूसरी ओर, सटीकता कुछ शताब्दियों तक समाप्त नहीं होगी।

आप int64 (BIGINT) के साथ सटीकता से बाहर निकलने के करीब कहीं नहीं हैं। अगर मैं वास्तव में केवल MySQL में उनके आदेश के लिए माइक्रोसेकंड टाइमस्टैम्प संग्रहीत कर रहा था, तो मैं DATETIME(6) के साथ जाऊंगा क्योंकि मुझे बहुत सारी तारीख अंकगणित मुफ्त में मिल जाएगी। अगर मैं इन-मेमोरी हाई वॉल्यूम ऐप कर रहा होता, तो मैं int64 का उपयोग करता।