هل يعتبر مشغل فرق التاريخ والوقت التوقيت الصيفي؟

Question

بقدر ما أعرف عامل الفرق في DateTime النوع يعتبر السنوات الكبيسة:لذا

new DateTime(2008, 3, 1) - new DateTime(2008, 2, 1) // should return 29 days
new DateTime(2009, 3, 1) - new DateTime(2009, 2, 1) // should return 28 days

ولكن ماذا عن التوقيت الصيفي؟

Answer 1

وأنا لا أعتقد أنها ستفعل ذلك. وثائق يقول ببساطة أن يتم تخزين التاريخ والوقت حيث بلغ عدد القراد منذ 12:00:00 منتصف الليل، 1 يناير 0001، ولكنه لا يقول فيه الزمنية منتصف الليل هو في الواقع - وأود أن نفترض أنه إذا كان دائما المخزنة داخليا في UTC، سيقال لذلك.

ويمكنك الحصول بسهولة حول هذا على الرغم من: فقط تفعل:

var difference = Dt1.ToUniversalTime() - Dt2. ToUniversalTime()

ووالتحويلات إلى UTC ستأخذ بعين الاعتبار الصيفي

Answer 2

لا يتعامل .NET مع التوقيت الصيفي بشكل صحيح، على الرغم من أنه يقدم الإجابات التي تريدها.أنت يريد إجابات غير صحيحة.

نسخة مختصرة:

• كيف يمكن لـ .NET معرفة أنه في عام 1977 كان التوقيت الصيفي ساريًا طوال العام، وذلك بسبب أزمة الطاقة؟

• كيف يمكن لـ .NET معرفة قواعد التوقيت الصيفي في إسرائيل، عندما يتم تحديد القواعد من سنة إلى أخرى من قبل الكنيست؟

• كيف يمكن لـ .NET أن تعرف أن الولايات المتحدة كانت تعمل بنظام التوقيت الصيفي على مدار العام خلال الحرب العالمية الثانية، ومن عام 1945 إلى عام 1966، تنوعت قواعد التوقيت الصيفي من منطقة إلى أخرى، ولا تزال القواعد تختلف من منطقة إلى أخرى.

يحاول .NET الانسحاب، ويستخدم قواعد التوقيت الصيفي الحالية، حتى لو لم تكن سارية المفعول أو ستكون سارية المفعول.والنتيجة هي أن تحصل على إجابات غير صحيحة، على الرغم من أنها ما تعتقد أنك تريده.

من ريمون تشينإدخال المدونة، لماذا يعتبر التوقيت الصيفي غير بديهي؟:

لماذا لا تستخدم وظائف تحويل المنطقة الزمنية (win32) المنطقة الزمنية المناسبة لهذا الوقت من العام؟

...

لا يحاول Win32 تخمين قواعد المنطقة الزمنية التي كانت سارية في ذلك الوقت الآخر.لذلك يقول Win32: "الخميس ، 17 أكتوبر 2002 8:45:38 AM PST".

ملحوظة: المحيط الهادئ معيار وقت.على الرغم من أن 17 أكتوبر كان خلال المحيط الهادئ ضوء النهار الوقت ، يعرض Win32 الوقت كوقت قياسي لأن هذا هو الوقت المناسب الآن.

يقول .NET: "حسنًا ، إذا كانت القواعد السارية الآن سارية أيضًا في 17 أكتوبر 2003 ، فسيكون ذلك وقت النهار"لذلك يعرض" الخميس ، 17 أكتوبر 2003 ، 9:45 صباحًا PDT " - وقت النهار.

لذا فإن الإجابات التي تحصل عليها خاطئة.ولكن بما أنك تتوقع الإجابة الخاطئة، فهذا ما تحصل عليه.

Answer 3

والتوقيت الصيفي هو أكثر تحديدا من عام 12 الزمنية والبلدان التي استخدمها.

والبلدان أو مجموعات البلدان المختلفة تستخدم تواريخ مختلفة لأنه عندما يحدث DST.

ولها قليلا من الألم حقا ناهيك عن الدول التي لا تفعل ذلك، أو أجزاء من الدول.

وعلى سبيل المثال ولاية كوينزلاند، AU doenst ديك DST الرغم بقية بلد ما.

وأنا لن يفاجأ إذا لم يحدث ذلك، في حال أنه لا أنه لن يكون قادرا على القيام بذلك مع من cultureinfo 9at على الأقل).

Answer 4

لن يحدث ذلك، وهو في الواقع لا يمكنه ذلك, ، استنادًا إلى حقيقة أنه لا يفرض عليك استخدام UTC لإنشاء DateTime ولا يسمح لك بتحديد ما إذا كان التوقيت الصيفي ساريًا عند إنشاء DateTime بقيمة توقيت محلي.علاوة على ذلك، فهو يسمح بأن يكون الوضع (LT أو UTC) "غير محدد"، وهو أمر غير طبيعي.

من خلال السماح بإنشاء قيم DateTime من قيم التوقيت المحلي، من الممكن إنشاء قيمة DateTime (المحددة بالتوقيت المحلي) والتي تكون غامضة (على سبيل المثال، أي وقت بين 1 و2 صباحًا في الثاني من نوفمبر في الولايات المتحدة، عندما تكرر الساعة المحلية نفسها ) ولا يمكن تحويلها بشكل حتمي مرة أخرى إلى UTC، ما لم يقدم المنشئ معلمة لتحديد ما إذا كان التوقيت الصيفي ساريًا للتوقيت المحلي المحدد.

نظرًا لعدم توفر مثل هذه المعلمة، فإن تصميم فئة DateTime غير مكتمل ومعيب، حيث فشل في مراعاة جميع المعلمات اللازمة لتحديد التوقيت المحلي بشكل صحيح.

أعتقد أن هذا هو سبب إنشاء فئة DateTimeOffset، والتي...إذا كنت في حيرة من أمرك بسبب وجود مثل هذه الفئة التي تبدو زائدة عن الحاجة ...لهذا السبب.

ونتيجة لذلك، لا يجب عليك أبدًا إجراء أي نوع من العمليات الحسابية مع أي مثيل DateTime لم يتم تعيينه على DateTimeMode.Utc.استخدم التوقيت العالمي المنسق (UTC) فقط.في الواقع لا يمكنك التحويل من أو إلى LT، لأنه تم اختراقه بواسطة خطأين مختلفين، في كلا الاتجاهين.1.تم إيقاف الانتقال من LT إلى UTC لأنه، كما ذكرنا سابقًا، لا يسمح لك بتحديد ما إذا كان التوقيت الصيفي ساريًا لتلك الساعة الغامضة في LT.أوه، فهو يسمح لك أيضًا بتحديد ساعة محلية وهو أمر مستحيل في الأساس، مثل الساعة التي نتخطىها عندما يتم ضبط الساعات للأمام.2.عند تحويل قيمة UTC في الماضي إلى توقيت محلي، يقوم Windows بإصلاح ذلك عن طريق تعويض التوقيت الصيفي بناءً على ما إذا كان ساريًا الآن، بدلاً من الوقت المحدد، وهو أمر غير صحيح على الإطلاق.بالطبع، ربما لاحظت هذه المشكلة عندما يظهر وقت التعديل الذي قمت بتدوينه أو تخزينه أو استخدامه باسم ملف في أحد الأيام ساعة إيقاف في مستكشف Windows.لا، أنت لست مجنونًا، نظام Windows به خطأ خطير، ولم يجدوا الوقت الكافي لإصلاحه في مكان ما بين إصدار DOS وأحدث إطار عمل .NET (حوالي عقدين من الزمن)!بالطبع، يؤثر هذا الخطأ على أنظمة CVS وأي شيء يتتبع أوقات التعديل.يقوم نظام الملفات FAT بتخزين الأوقات بالأوقات المحلية، مما يعني أنه فاشل تمامًا.

Answer 5

واختبار ذلك ونرى!

وانها مجرد سهلة لكتابة اختبار كما فعلت في الحالة DST كما هو الحال بالنسبة للحالة سنة كبيسة.