Mysql
 sql >> डेटाबेस >  >> RDS >> Mysql

Laravel SQLSTATE[22007]:अमान्य डेटाटाइम प्रारूप:1292 गलत डेटाटाइम मान:'2019-03-10 02:00:39' कॉलम 'updated_at' के लिए (दिन के उजाले की बचत?)

मुझे पता चला कि समस्या मेरे MySQL सर्वर के time_zone . के कारण थी सेटिंग को SYSTEM पर सेट किया जा रहा है (और मेरा सिस्टम यूएस सेंट्रल है)। Laravel टाइमस्टैम्प प्रदान कर रहा है जो पहले से ही UTC में परिवर्तित हो चुके थे, लेकिन मेरा डेटाबेस time_zone के कारण उन्हें US Central के रूप में व्याख्यायित कर रहा है सेटिंग। समय वास्तव में परिवर्तित किया जा रहा है फिर से आंतरिक रूप से MySQL द्वारा "असली" यूटीसी यूनिक्स टाइमस्टैम्प प्रतिनिधित्व (जो गलत होगा क्योंकि यह समय क्षेत्र द्वारा ऑफसेट है), भले ही वे प्रत्येक क्वेरी में पहले से ही यूटीसी प्रतीत होते हैं क्योंकि वे पढ़ने के लिए फिर से यूएस सेंट्रल में परिवर्तित हो जाते हैं ( मुझे सही पता है)।

इस वजह से, स्थानीय समयानुसार 20:00:39 (8:00 PM) पर मेरा Laravel UTC टाइमस्टैम्प 02:00:39 है। MySQL इन समयों को यूएस सेंट्रल समय के रूप में व्याख्या करता है, और क्योंकि समय 02:00 और 03:00 के बीच है (जो तब होता है जब घड़ियां यूएस सेंट्रल के लिए आगे जाती हैं), समय अमान्य है।

Laravel एप्लिकेशन के लिए सबसे अच्छा समाधान प्रत्येक डेटाबेस कनेक्शन को +00:00 . का उपयोग करने के लिए बाध्य करना है टाइमज़ोन (या जो भी आपने config/app.php . में एप्लिकेशन टाइमज़ोन के रूप में सेट किया है ) इसलिए कोई द्वितीयक रूपांतरण नहीं हो रहा है। यह config/database.php . में किया जा सकता है :

'mysql' => [
    // ...

    'timezone'  => '+00:00'
],

इस तरह आप अपने डेटाबेस सर्वर की दया पर नहीं हैं यदि उसके पास एक कॉन्फ़िगर किया गया समय क्षेत्र है जो आपके लारवेल एप्लिकेशन से अलग है। दूसरा विकल्प डेटाबेस के time_zone . को बदलना है सेटिंग, लेकिन फिर भी यदि आप कभी भी होस्ट बदलते हैं या किसी भी कारण से सर्वर को फिर से बनाने की आवश्यकता होती है (और समय क्षेत्र को फिर से सही ढंग से कॉन्फ़िगर नहीं करते हैं), या सर्वर पर अन्य डेटाबेस को प्रभावित करते हैं, तो आप फिर भी बग के पुनरावर्ती होने का जोखिम उठाते हैं।

महत्वपूर्ण नोट:चूंकि पिछले सभी टाइमस्टैम्प MySQL द्वारा कॉन्फ़िगर किए गए समय क्षेत्र से UTC यूनिक्स टाइमस्टैम्प में आंतरिक रूप से ऑफसेट किए जा रहे थे (जो, फिर से, गलत थे क्योंकि रिकॉर्ड पहले से ही UTC थे) इसे सही करने के लिए डेटा माइग्रेशन चलाना आवश्यक हो सकता है पुराने टाइमस्टैम्प। मैंने आगे जांच नहीं की है क्योंकि मेरे आवेदन के लिए यह कोई फर्क नहीं पड़ता कि पुराने टाइमस्टैम्प कुछ घंटों में गलत थे।




  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. MySQL:रैंडम एंट्री का चयन करें, लेकिन कुछ प्रविष्टियों की ओर वजन

  2. मुझे mysqli (डेटाबेस) कनेक्शन कब बंद करना होगा?

  3. Mysqli अद्यतन सेट जहां वाक्यविन्यास त्रुटि

  4. पाइथन के साथ MySQL को कैसे अपडेट करें जहां फ़ील्ड और प्रविष्टियां एक शब्दकोश से हैं?

  5. #1221 - UPDATE और ORDER BY का गलत उपयोग