كيف يعمل DateTime.ToUniversalTime()؟

Question

كيف يتم التحويل إلى UTC من المعيار DateTime تنسيق العمل؟

وبشكل أكثر تحديدًا، إذا قمت بإنشاء ملف DateTime الكائن في منطقة زمنية واحدة ثم قم بالتبديل إلى منطقة زمنية أخرى وتشغيله ToUniversalTime() عليه، كيف يعرف أن التحويل قد تم بشكل صحيح وأن الوقت لا يزال يمثل بدقة؟

Answer 1

وليس هناك توقيت الضمني تعلق على وجوه DateTime. إذا قمت بتشغيل ToUniversalTime() على ذلك، فإنه يستخدم التوقيت من السياق الذي يتم تشغيل التعليمات البرمجية في.

وعلى سبيل المثال، إذا كنت إنشاء DateTime من عصر 1/1/1970، انه يعطيني نفس الكائن DateTime بغض النظر عن مكان في العالم أنا.

إذا قمت بتشغيل ToUniversalTime() عليه عندما أكون تشغيل التعليمات البرمجية في غرينتش، ثم أحصل نفس الوقت. إذا كنت تفعل ذلك بينما أنا أعيش في فانكوفر، ثم أحصل على وجوه DateTime إزاحة -8 ساعات.

وهذا هو السبب في أنه من المهم لتخزين المعلومات المتعلقة الوقت في قاعدة البيانات الخاصة بك مرات UTC عندما كنت في حاجة للقيام بأي نوع من تحويل التواريخ أو الترجمة. النظر في ما إذا مصدر برنامج الخاص حصلت على نقلها إلى مرفق الخادم في توقيت آخر؛)

وتحرير: مذكرة من الجواب جويل - يتم كتابتها الأجسام DateTime افتراضيا كما DateTimeKind.Local. إذا كنت تحليل التاريخ وتعيينه DateTimeKind.Utc، ثم ToUniversalTime() يؤدي أي تحويل.

وهنا مقالا عن "أفضل الممارسات الترميز مع تايمز التاريخ" ومقالا عن تحويل DateTimes مع صافي .

Answer 2

أولاً، يتم التحقق مما إذا كان Kind التابع DateTime ومن المعروف أن يكون UTC بالفعل.إذا كان الأمر كذلك، فإنه يُرجع نفس القيمة.

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

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

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

القيمة التي تم إرجاعها سيكون لها Kind ل DateTimeKind.Utc, ، فإذا اتصلت ToUniveralTime على أنه لن يتم تطبيق الإزاحة مرة أخرى.(هذا تحسن كبير مقارنة بـ .NET 1.1!)

إذا كنت تريد منطقة زمنية غير محلية، فيجب عليك استخدام TimeZoneInfo والذي تم تقديمه في .NET 3.5 (توجد حلول مخترقة للإصدارات السابقة، لكنها ليست جيدة).لتمثيل لحظة زمنية، يجب أن تفكر في استخدام DateTimeOffset والذي تم تقديمه في .NET 2.0SP1 و.NET3.0SP1 و.NET 3.5.ومع ذلك، لا يزال هذا ليس له منطقة زمنية فعلية مرتبطة به - مجرد إزاحة من التوقيت العالمي المنسق (UTC).وهذا يعني أنك لا تعرف التوقيت المحلي الذي سيكون بعد ساعة واحدة، على سبيل المثال - يمكن أن تختلف قواعد التوقيت الصيفي بين المناطق الزمنية التي حدث أنها تستخدم نفس الإزاحة لتلك اللحظة المحددة. TimeZoneInfo تم تصميمه لأخذ القواعد التاريخية والمستقبلية في الاعتبار، بدلاً من TimeZone وهو مبسط إلى حد ما.

بشكل أساسي، يعد الدعم في .NET 3.5 أفضل بكثير مما كان عليه، لكنه لا يزال يترك شيئًا مما هو مرغوب فيه بالنسبة لحسابات التقويم المناسبة.أي شخص يتوهم النقل توقيت جودا إلى الشباك؟;)

Answer 3

womp قال ، مع إضافة أن يتحقق الملكية التحيات والتاريخ والوقت لمعرفة ما اذا كان قد <م> بالفعل أن يكون تاريخ UTC.

Answer 4

وDateTime.ToUniversalTime يزيل التوقيت إزاحة التوقيت المحلي لتطبيع والتاريخ والوقت إلى UTC. إذا كنت ثم استخدام DateTime.ToLocalTime على قيمة تطبيع في توقيت آخر، سيتم إضافة خط الزمن إزاحة أن التوقيت لقيمة تطبيع للتمثيل الصحيح في هذا التوقيت.