🙋 📇 🗂️ एक वेब अनुप्रयोग में समय क्षेत्र की समस्या का समाधान ♋️ 🚣🏻 🙇🏿

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

DATETIME डेटा प्रकार का उपयोग दिनांक और समय को 1000-01-01 00:00:00 - 9999-12-31-11:59 रेंज में स्टोर करने के लिए किया जाता है। नमूना लेते समय, डेटाबेस की अस्थायी सेटिंग की परवाह किए बिना, दिनांक को बिल्कुल उसी तरह निकाला जाता है जैसे कि इसे रिकॉर्ड किया गया था। आप दिनांक को किसी विशिष्ट समय क्षेत्र में CONVERT_TZ फ़ंक्शन के साथ परिवर्तित कर सकते हैं या मैन्युअल रूप से अन्य तरीकों से समायोजित कर सकते हैं।

समय क्षेत्र के आधार पर, दिनांकित करने के लिए एक अन्य प्रकार, टाइमस्टेम , MySQL में भंडारण की तारीखों के लिए एकमात्र प्रकार है। यह डेटा प्रकार, जब सहेजा जाता है, स्थानीय से UTC तक के समय को परिवर्तित करता है, और जब इसे वापस ज़ोन में लाया जाता है। महत्वपूर्ण रूप से, सभी ऑपरेशन और आउटपुट DATETIME प्रकार (MySQL 5.0 के बाद से) के समान हैं।
इस प्रकार में बहुत सुविधाजनक विशेषताएं भी हैं - यह आपको डिफ़ॉल्ट मान के रूप में अब () को रिकॉर्ड करने के साथ-साथ सेट करने की अनुमति देता है।
TIMESTAMP का नुकसान सीमित तिथि सीमा (1970 - 2038) है। इस कारण से, यह ऐतिहासिक घटनाओं या दूर के भविष्य की घटनाओं को संग्रहीत करने के लिए उपयुक्त नहीं है, लेकिन यहां समय क्षेत्र महत्वपूर्ण नहीं हैं।

इसलिए, हमें एक समाधान खोजने की आवश्यकता थी जिसमें कोड और एसक्यूएल प्रश्नों के बड़े पैमाने पर पुनर्लेखन की आवश्यकता नहीं थी, इसलिए प्रश्नों में समय को समायोजित करने या PHP टूल का उपयोग करने के विकल्प सफल नहीं दिखे।
नतीजतन, निम्नलिखित किया गया:
- डेटाबेस में सभी तिथियों को TIMESTAMP में बदल दिया गया है
- जब उपयोगकर्ता सत्र शुरू करते हैं, तो निम्न कोड जैसा कुछ जोड़ा गया था जो MySQL और PHP के लिए स्थान निर्धारित करता है:

<?php
date_default_timezone_set($user->timezone);
db::q("SET `time_zone`='".date('P')."'");
?>

Date_default_timezone_set () फ़ंक्शन समय क्षेत्र के पहचानकर्ता स्ट्रिंग के पैरामीटर के रूप में लेता है, उदाहरण के लिए, "यूरोप / मॉस्को" और इसे सभी दिनांक और समय के कार्यों के लिए सेट करता है।
SQL क्वेरी वर्तमान कनेक्शन के भीतर सभी प्रश्नों के लिए समय क्षेत्र निर्धारित करता है ( आधिकारिक प्रलेखन में अधिक)।
नतीजतन, यह समाधान अलग-अलग समय क्षेत्रों में महान काम करता है और समस्या को हल करने के लिए एक कारगर तरीका है।

इस पोस्ट के निष्कर्ष सरल हैं: एक विस्तृत भौगोलिक कवरेज वाली परियोजनाओं के लिए, टाइमस्टैम्प प्रकार को हमेशा टाइमस्टैम्प स्टोर करने के लिए उपयोग किया जाना चाहिए, जो भविष्य में सिरदर्द से बचने में मदद करेगा।

UPD: जैसा कि ठीक से उल्लेख किया गया है, यह आधार के लिए ऑफ़सेट द्वारा नहीं (जैसा कि ऊपर कोड में है) समय निर्धारित करने के लिए अधिक सही है, लेकिन समय क्षेत्र के पहचानकर्ता द्वारा, अन्यथा, इस क्षेत्र के लिए दिन के समय की बचत और अन्य ऐतिहासिक परिवर्तनों पर ध्यान नहीं दिया जाता है। इस स्थिति में, आपको mysql_tzinfo_to_sql का उपयोग करके डेटाबेस में संबंधित डेटा लोड करना होगा और उन्हें समयबद्ध तरीके से अपडेट करना होगा।

एक वेब अनुप्रयोग में समय क्षेत्र की समस्या का समाधान

More articles: