Heidisql: عرض طابع زمني خاطئ كقيمة تاريخ في الشبكة

مرحبًا mpaland ، تعمل MariaDB مع المنطقة الزمنية الصحيحة Europe / Berlin؟
أنا لا أتعامل مع الكثير من التحويلات ، يكتب الطابع الزمني إلى UTC ، أليس كذلك؟ و MySQL تتحول إلى منطقتك الزمنية؟

حاولت إعادة الإنتاج ولكن على الخوادم التي أمتلكها بدون تثبيت المناطق الزمنية :(

lukinhaspm لا يتعلق الأمر بالخادم ، إنها مجرد مسألة تمثيل الطابع الزمني الصحيح في HeidiSQL. من المفترض دائمًا أن تكون UNIX TIMESTAMP في ثوانٍ بعد 1970-01-01 00:00:00 بالتوقيت العالمي المنسق.

يمكنك تقديم مثل هذا الطابع الزمني بدقة بالتوقيت العالمي المنسق ، وهو أمر جيد ، أو في منطقة زمنية معينة (خاصة في الغالب). القيام بذلك ، يحتاج إلى المنطقة الزمنية الصالحة في تاريخ الطابع الزمني ، وليس في التاريخ الفعلي.
يبدو أن HeidiSQL يأخذ التاريخ الفعلي. لم ألق نظرة على الكود الخاص به بعد ، لذا فهو مجرد تكهنات.

mpaland أفهم وأوافق!

لقد تحققت في هذا قليلاً. لسوء الحظ ، لا يبدو الحل سهلاً.
المشكلة هي قواعد DST (التوقيت الصيفي) المعقدة في جميع أنحاء العالم ، بل والأسوأ من ذلك ، شكلها المتغير باستمرار وغير الثابت.
لتصحيح التوقيت المحلي لطابع زمني معين ، من الضروري معرفة قاعدة التوقيت الصيفي الدقيقة التي تم تطبيقها محليًا في وقت الطوابع الزمنية.
تحتاج مكتبة التحويل إلى تتبع جميع تغييرات قواعد التوقيت الصيفي في كل بلد على مر السنين لحساب الإزاحة لأي نقطة في الماضي.
يتجاهل Windows هذه المشكلة تمامًا ويتحول دائمًا وفقًا لقاعدة _actual_ DST في وقت التحويل.
للقيام بذلك بشكل صحيح ، من الضروري استخدام إحدى مكتبات المنطقة الزمنية / DST المتقدمة حقًا حول الشبكة.

على الرغم من أن معظم ما ذكرهmpaland حول الحاجة إلى معرفة قاعدة التوقيت الصيفي المطبقة عند إنشاء الطابع الزمني صحيحة من الناحية الفنية (إذا قمنا بإسقاط التوقيت الصيفي ، على سبيل المثال ، فإن جميع اللحظات المسجلة أثناء نشاطها ستنتقل إلى التوقيت النسبي غير الصيفي توفير الوقت) ، فلا يزال من الممكن استخدام قواعد التوقيت الصيفي الحالية لعرض الوقت للطابع الزمني بشكل صحيح.

1584975600 و 1585576800 كلاهما 16:00 في أوروبا / مدريد ، لكن heidisql يمثل أحدهما بشكل غير صحيح (اعتمادًا على ما إذا كنا في التوقيت الصيفي أم لا)

قد يكون من الممكن عرض هذه الحالات بشكل صحيح دون أن تكون متاعب كبيرة بمجرد التحقق مما إذا كان الوقت الناتج يجب أن يكون في التوقيت الصيفي أم لا وتطبيق الإزاحة الصحيحة.

على الرغم من أنه ليس حلاً مثاليًا ، إلا أنني أقول إنه ربما يغطي معظم حالات الاستخدام ، ومن المحتمل أن يتم رصد حالات الحافة بسهولة ، إنها مساعدة صغيرة للمطورين للتحقق من شيء ما على ما يرام من عرض المستخدم النهائي الموثوق به على أي حال.