हम इसके बजाय ऐसा कर सकते हैं:
FROM_UNIXTIME(0) + INTERVAL -957632400 SECOND
FROM_UNIXTIME फ़ंक्शन TIMESTAMP . के लिए स्वीकार्य सीमा द्वारा सीमित है डेटाटाइप, जो मानक 32-बिट अहस्ताक्षरित इंट रेंज 1970-01-01 थ्रू 2038-01-कुछ है। अन्य सॉफ़्टवेयर को 64-बिट हस्ताक्षरित पूर्णांकों का समर्थन करने के लिए अद्यतन किया गया है, लेकिन MySQL अभी तक वह कार्यक्षमता प्रदान नहीं करता है (कम से कम 5.1.x में नहीं)।
MySQL में समाधान TIMESTAMP का उपयोग करने से बचना है डेटाटाइप और DATETIME . का उपयोग करना इसके बजाय डेटाटाइप, जब हमें एक बड़ी रेंज की आवश्यकता होती है (उदाहरण के लिए 1 जनवरी, 1970 से पहले की तारीखें)।
हम DATE_ADD . का उपयोग कर सकते हैं 1 जनवरी, 1970 से सेकंड घटाने का कार्य इस तरह करें:
SELECT DATE_ADD('1970-01-01 00:00:00',INTERVAL -957632400 SECOND)
नायब उन प्रकार की गणना करने में आपको शायद यूटीसी से टाइमज़ोन "ऑफ़सेट" के लिए खाते की आवश्यकता होगी। MySQL DATETIME मानों की व्याख्या time_zone . में निर्दिष्ट के रूप में करने जा रहा है UTC के बजाय वर्तमान MySQL सत्र की सेटिंग (time_zone = '+00:00' )
अनुसरण करें:
प्रश्न: ठीक है, इसका मतलब है कि अगर हम '1970-01-01 00:00:00' से नीचे की तारीखों का चयन करते हैं तो ऋणात्मक मान डीबी में सहेजता है अन्यथा यह सकारात्मक होगा। सही? - सॉफ्ट जीनिक
ए: उह, नहीं। यदि आप 1 जनवरी, 1970 से पहले दिनांक/डेटाटाइम मान चुनते हैं, तो MySQL 1 जनवरी, 1970 से पहले DATE या DATETIME मान लौटाएगा। यदि आप 1 जनवरी, 1970 से पहले DATE या DATETIME मान संग्रहीत करते हैं, तो MySQL 1 जनवरी से पहले DATE या DATETIME मान संग्रहीत करेगा। , 1970, उन डेटाटाइप द्वारा समर्थित स्वीकार्य सीमा के भीतर। (कुछ ऐसा 0001-01-01 थ्रू 9999 ?)
यदि आपको डेटाबेस में वास्तव में वास्तव में बड़े सकारात्मक और नकारात्मक पूर्णांकों को संग्रहीत करने की आवश्यकता है, तो आप संभवतः उन्हें BIGINT के रूप में परिभाषित कॉलम में संग्रहीत करेंगे। ।
DATE कॉलम के आंतरिक प्रतिनिधित्व के लिए 3-बाइट स्टोरेज की आवश्यकता होती है, और DATETIME को 8-बाइट स्टोरेज की आवश्यकता होती है (MySQL संस्करण 5.6.4 तक। DATE और DATETIME मानों का आंतरिक प्रतिनिधित्व और संग्रहण 5.6.4 में बदल गया)
तो नहीं, MySQL 1970 से पहले के दिनांक मानों को "नकारात्मक पूर्णांक" के रूप में संग्रहीत नहीं करता है।
यदि आप इसके बारे में थोड़ा सोचते हैं, तो MySQL जो भी भंडारण तंत्र चाहता है उसे लागू करने के लिए स्वतंत्र है। (और प्रत्येक स्टोरेज इंजन डिस्क पर उस प्रतिनिधित्व को क्रमबद्ध करने के लिए स्वतंत्र है, हालांकि वह चाहता है।)
डेट के लिए 3 बाइट क्यों?
एक विकल्प MySQL के पास है (और मैं इसका प्रतिनिधित्व नहीं कर रहा हूं कि यह इस तरह से किया जाता है) तारीख को इसके साल के महीने और दिन के घटकों में विभाजित करना हो सकता है।
श्रेणी में पूर्णांक मानों का प्रतिनिधित्व - आवश्यक है -
-
0 - 9999 -14 बिट -
0 - 12 -4 बिट -
0 - 31 -5 बिट
यह कुल 23 बिट्स है, जो आसानी से 3 बाइट्स में फिट होने के लिए होता है। यह सिर्फ यह दर्शाता है कि MySQL के लिए 1 जनवरी 1970 से पहले दिनांक मानों को ऋणात्मक पूर्णांकों के रूप में प्रस्तुत करना आवश्यक नहीं है, इसलिए हमें यह धारणा नहीं बनानी चाहिए कि यह करता है। (लेकिन हम वास्तव में केवल इस स्तर के विवरण से चिंतित होंगे यदि हम MySQL के लिए स्टोरेज इंजन पर काम कर रहे थे।)
