Heidisql: ग्रिड में दिनांक मान के रूप में गलत टाइमस्टैम्प प्रदर्शन

अरे @mpaland , आपका टाइमज़ोन यूरोप/बर्लिन के साथ चल रहा है?
मैं बहुत सारे रूपांतरणों को संभालता नहीं हूं, टाइमस्टैम्प यूटीसी को लिखता है, है ना? और MySQL आपके टाइमज़ोन में परिवर्तित हो जाता है?

मैंने पुन: पेश करने की कोशिश की, लेकिन मेरे पास जो सर्वर हैं, वे बिना टाइमज़ोन स्थापित किए हैं :(

@lukinhaspm यह सर्वर का कोई सवाल नहीं है, यह सिर्फ HeidiSQL में सही टाइमस्टैम्प प्रतिनिधित्व का सवाल है। UNIX TIMESTAMP हमेशा 1970-01-01 00:00:00 UTC के बाद सेकंड में होना चाहिए।

आप इस तरह के टाइमस्टैम्प को यूटीसी में सख्ती से पेश कर सकते हैं, जो ठीक है, या एक निश्चित (ज्यादातर खुद के) टाइमज़ोन में। ऐसा करने के लिए, टाइमस्टैम्प तिथि पर मान्य टाइमज़ोन की आवश्यकता होती है, वास्तविक तिथि पर नहीं ।
ऐसा लगता है कि HeidiSQL वास्तविक तिथि लेता है। मैंने अभी तक इसका कोड नहीं देखा है, इसलिए यह सिर्फ एक अनुमान है।

@mpaland मैं समझता हूं और सहमत हूं!

मैंने इसकी थोड़ी और जांच की। दुर्भाग्य से समाधान आसान नहीं लगता है।
समस्या दुनिया भर में जटिल डीएसटी (डेलाइट सेविंग टाइम) नियम हैं और इससे भी बदतर उनके लगातार बदलते, गैर-स्थिर रूप हैं।
एक निश्चित युग टाइमस्टैम्प के लिए स्थानीय समय डीएसटी को ठीक करने के लिए सटीक डीएसटी नियम को जानना आवश्यक है जो स्थानीय रूप से टाइमस्टैम्प समय पर लागू किया गया था।
एक रूपांतरण पुस्तकालय को अतीत में किसी भी बिंदु के लिए ऑफसेट की गणना करने के लिए प्रत्येक देश में सभी डीएसटी नियम परिवर्तनों का ट्रैक रखने की आवश्यकता है।
विंडोज इस समस्या को पूरी तरह से नजरअंदाज कर देता है और हमेशा _actual_ DST नियम के अनुसार रूपांतरण के समय परिवर्तित करता है।
इसे सही तरीके से करने के लिए, नेट के आसपास वास्तव में उन्नत टाइमज़ोन/डीएसटी पुस्तकालयों में से एक का उपयोग करना आवश्यक है।

हालाँकि टाइमस्टैम्प बनाते समय लागू किए गए DST नियम को जानने की आवश्यकता के बारे में @mpaland ने जो कुछ कहा है, वह तकनीकी रूप से सही है (यदि हम डेलाइट सेविंग को छोड़ देते हैं, उदाहरण के लिए, सक्रिय होने के दौरान रिकॉर्ड किए गए सभी क्षण सापेक्ष गैर-डेलाइट में "शिफ्ट" होंगे समय की बचत), वर्तमान डीएसटी नियमों का उपयोग टाइमस्टैम्प के लिए समय को ठीक से प्रदर्शित करने के लिए अभी भी संभव है।

१५८४९७५६०० और १५८५५७६८०० दोनों यूरोप/मैड्रिड में १६:०० हैं, लेकिन हेइडिसक्ल गलत तरीके से उनमें से एक का प्रतिनिधित्व करता है (यह निर्भर करता है कि हम डेलाइट सेविंग टाइम पर हैं या नहीं)

परिणामी समय डेलाइट सेविंग टाइम पर होना चाहिए या नहीं और सही ऑफसेट को लागू करने से बड़ी परेशानी के बिना इन मामलों को सही ढंग से प्रदर्शित करना संभव हो सकता है।

भले ही यह एक सही समाधान नहीं है, मैं कहूंगा कि यह शायद अधिकांश उपयोग के मामलों को कवर करता है, और किनारे के मामलों को आसानी से देखा जा सकता है, देवों के लिए यह एक छोटी सी मदद है कि किसी अंतिम उपयोगकर्ता विश्वसनीय प्रदर्शन की तुलना में कुछ ठीक है।