في الآونة الأخيرة ، كنت أعمل على مهمة إضافة مناطق زمنية إلى مكتبة تقويم JS التي يحتفظ بها فريقي. كنت أدرك جيدًا دعم المنطقة الزمنية غير المجدية في جافا سكريبت ، لكنني كنت آمل أن يؤدي تجريد كائنات البيانات الموجودة إلى تسهيل حل معظم الصعوبات.
ومع ذلك ، ذهبت أحلامي إلى الغبار. عندما بحثت في المهمة ، أدركت أنه من الصعب حقًا العمل مع المناطق الزمنية بهذه اللغة. كان تنفيذ شيء أكثر تعقيدًا من مجرد تنسيق عرض الوقت وحساب التاريخ باستخدام عمليات معقدة (وظائف التقويم) أمرًا بالغ الصعوبة. لقد اكتسبت خبرة قيمة في حل هذه المشكلة ، وهذا ينطوي على صعوبات جديدة.
في هذه المقالة ، أريد مناقشة ما صادفته وكيف تم حله. بينما كنت أكتب النص ، أدركت أن السبب وراء كل المصاعب كان فهمي السيئ لموضوع المناطق الزمنية. في ضوء هذا الوعي ، أقترح أولاً التحدث بالتفصيل حول التعريف والمعايير ، وبعد ذلك فقط انتقل إلى JavaScript.
ما هي المنطقة الزمنية؟
المنطقة الزمنية هي منطقة جغرافية تستخدم نفس التوقيت المحلي الذي حددته الحكومة. ترتبط العديد من الدول تمامًا بأية مناطق زمنية معينة ، وفي مناطق الدول الكبيرة ، مثل روسيا والولايات المتحدة الأمريكية ، يتم استخدام عدة مناطق زمنية. من الغريب أنه على الرغم من أن الصين أيضًا كبيرة بدرجة كافية ، إلا أنها لا تقبل سوى منطقة زمنية واحدة. يؤدي هذا أحيانًا إلى مواقف غريبة عندما تبدأ شروق الشمس في الجزء الغربي من البلاد في حوالي الساعة 10 صباحًا.
GMT و UTC و Offset
GMT
تم تخصيص التوقيت المحلي لكوريا الجنوبية بالتوقيت العالمي
GMT+09:00 . GMT تعني توقيت غرينتش (GMT) ، أي هذه المرة على مدار الساعة من المرصد الملكي في غرينتش ، المملكة المتحدة. وهي تقع على خط الطول الرئيسي. بدأت الإشارة اللاسلكية لنظام GMT في البث في 5 فبراير 1924 ، وتحولت هي نفسها إلى معيار عالمي في 1 يناير 1972.
UTC
يعتقد الكثير من الناس أن GMT و UTC هما نفس الشيء ، وغالبًا ما يستخدمونها كنظم قابلة للتبديل. لكن هذا خطأ. ظهر نظام UTC في عام 1972 كطريقة للتعويض عن تأثير دوران الأرض. يعتمد النظام على التوقيت الذري الدولي ، ويتم حسابه حسب عدد مرات تكرار الاهتزازات الكهرومغناطيسية لذرات السيزيوم. وبعبارة أخرى ، UTC هو بديل أكثر دقة ل GMT. على الرغم من أن الفرق في الوقت الفعلي بين النظامين صغير جدًا ، إلا أنه من الأفضل لمطوري البرامج الاعتماد على التوقيت العالمي المتفق عليه (UTC).
حقيقة مثيرة للاهتمام: عندما كان UTC لا يزال قيد التطوير ، اقترح في البلدان الناطقة باللغة الإنجليزية أن نسميها CUT (التوقيت العالمي المنسق) ، والبلدان الناطقة باللغة الفرنسية - TUC (Temps Universal Coordonn). ومع ذلك ، لم يتمكن أي من المخيمات من الفوز ، واتفقوا على استدعاء النظام UTC ، وهجاء من كل من الخيارات المقترحة (C ، T و U).
إزاحة
+09:00 UTC+09:00 تعني أن التوقيت المحلي يتقدم 9 ساعات عن التوقيت
+09:00 القياسي بالتوقيت العالمي. أي عندما تكون الساعة 9 مساءً في كوريا الجنوبية ، ستكون الظهر في منطقة UTC. يُطلق على الفرق بين التوقيت العالمي الموحد UTC والتوقيت المحلي "الإزاحة" ، والتي يتم التعبير عنها كقيم موجبة أو سلبية:
+09:00 ،
-03:00 ، إلخ.
في كثير من البلدان ، من المعتاد إعطاء أسماء المناطق الزمنية الفريدة الخاصة بك. على سبيل المثال ، تسمى المنطقة الزمنية لكوريا الجنوبية KST (Korea Standard Time) ، ويتم التعبير عن
KST = UTC+09:00 كـ
KST = UTC+09:00 . ومع ذلك ، يتم استخدام الإزاحة
+09:00 ليس فقط من قبل كوريا الجنوبية ، ولكن أيضًا من قِبل اليابان وإندونيسيا والعديد من البلدان الأخرى ، وبالتالي ، فإن العلاقة بين الإزاحة والأحزمة لا يتم التعبير عنها على أنها 1: 1 ، ولكن كـ 1: N. يتم عرض قائمة بالدول التي بها إزاحة
+09:00 هنا .
بعض الإزاحات لا تعمل فقط لساعات. على سبيل المثال ، في كوريا الشمالية ، الوقت القياسي هو
+08:30 ، بينما في أستراليا في بعض المناطق
+8:45 ،
+09:30 و
+10:30 .
قائمة كاملة من إزاحة UTC
هنا .
المنطقة الزمنية! == الإزاحة؟
كما قلت ، نستخدم أسماء المناطق الزمنية (KST ، JST) مع الإزاحة على أنها قابلة للتبادل ، دون التمييز بينها. ولكن سيكون من الخطأ النظر في نفس الوقت وتحول منطقة معينة. هناك عدة أسباب:
التوقيت الصيفي (DST)
في بعض البلدان ، هذا المصطلح غير معروف ، لكن في كثير من الدول ، يتم ممارسة التوقيت الصيفي ، وخاصة في أوروبا. لهذا ، يتم اعتماد المصطلح الدولي DST - التوقيت الصيفي. وهذا يعني تحريك الساعة في الصيف لمدة ساعة واحدة قبل الوقت القياسي النسبي.
على سبيل المثال ، تستخدم كاليفورنيا توقيت المحيط الهادي PST (التوقيت الباسيفيكي القياسي) في الشتاء و PDT (توقيت المحيط الهادي الصيفي ،
UTC-07:00 ) في الشتاء. في الولايات المتحدة وكندا ، يتم استخدام المصطلح Pacific Time (PT، Pacific Time) للمناطق التي تستخدم منطقتين زمنيتين.
متى يبدأ وقت الصيف وينتهي؟ كل هذا يتوقف على البلد. على سبيل المثال ، في الولايات المتحدة الأمريكية وكندا حتى عام 2006 ، تم استخدام التوقيت الصيفي من الساعة 2 صباحًا يوم الأحد الأول من أبريل إلى الساعة 12 صباحًا في يوم الأحد الأخير من شهر أكتوبر. ومنذ عام 2007 ، بدأ وقت الصيف في العد من ليلتين في يوم الأحد الثاني من شهر مارس إلى ليلتين في يوم الأحد الأول من شهر نوفمبر. في أوروبا ، تمارس بلدان مختلفة الاستخدام التدريجي لـ DST اعتمادًا على كل منطقة زمنية.
هل المناطق الزمنية تتغير؟
تحدد كل دولة نفسها المناطق الزمنية التي يجب استخدامها ، وبالتالي يمكن أن يتغير التوقيت المحلي لأي أسباب سياسية و / أو اقتصادية. على سبيل المثال ، في الولايات المتحدة ، تم تغيير حدود التوقيت الصيفي في عام 2007 لأن جورج دبليو بوش بدأ سياسة الطاقة في عام 2005. اعتادت مصر وروسيا التحول إلى التوقيت الصيفي ، لكنهما تخلى عنهما منذ عام 2011.
في بعض الحالات ، يمكن للحكومة تغيير ليس فقط التوقيت الصيفي ، ولكن أيضًا التوقيت القياسي. على سبيل المثال ، استخدمت ساموا في وقت سابق الإزاحة
UTC-10:00 ، لكنهم تحولوا بعد ذلك إلى
UTC+14:00 لتقليل الخسائر في التجارة بسبب اختلاف التوقيت مع أستراليا ونيوزيلندا. أدى هذا القرار إلى خسارة حياة البلاد طوال اليوم - 30 ديسمبر 2011 ، كما ذكرت
الصحف في جميع أنحاء العالم .
في هولندا ، تم استخدام إزاحة
+0:19:32.13 منذ عام 1909 ، ومنذ عام 1937 تحولت البلاد إلى
+00:20 ، ومن 1940 إلى
+01:00 ، ومنذ ذلك الحين لم يتغير الوقت الرئيسي هناك.
المنطقة الزمنية 1: إزاحة N
لذلك ، يمكن أن يكون للمنطقة الزمنية إزاحة واحدة أو أكثر. يعتمد أي وقت مقبول كمعيار على الأسباب السياسية و / أو الاقتصادية الحالية في بلد معين.
في الحياة اليومية ، لا يسبب هذا صعوبات حتى تحاول تنظيم هذه البيانات وفقًا لبعض القواعد. تخيل أنك تريد ضبط الوقت القياسي على هاتفك الذكي باستخدام نوع من التحيز. إذا كنت تعيش في منطقة تمارس فيها التوقيت الصيفي ، فيجب أن يعرف هاتفك الذكي متى يجب أن تذهب ذهابًا وإيابًا. وهذا يعني أنك تحتاج إلى تأسيس العلاقة بين التوقيت القياسي والصيف في منطقة زمنية واحدة (على سبيل المثال ، توقيت المحيط الهادئ).
ولكن هذا لا يمكن القيام به مع اثنين من القواعد البسيطة. على سبيل المثال ، عندما تم تغيير بداية ونهاية التوقيت الصيفي في الولايات المتحدة الأمريكية في عام 2007 ، في 31 مايو 2006 ، كان من المفترض استخدام PDT (
-07:00 )
-07:00 قياسي ، وفي 31 مارس 2007 - PST (
-08:00 ). اتضح أنه من أجل الرجوع إلى منطقة زمنية محددة ، تحتاج إلى معرفة محفوظات التغيير بأكملها في المناطق الزمنية أو تاريخ تغيير قواعد التوقيت الصيفي.
يمكنك القول: "المنطقة الزمنية في نيويورك هي PST (
-08:00 )." ومع ذلك ، يجب توضيح ذلك: "المنطقة الزمنية الحالية في نيويورك هي PST." علاوة على ذلك ، من أجل التنفيذ الدقيق للنظام ، تحتاج إلى استخدام تعبير أكثر دقة. ننسى مصطلح "المنطقة الزمنية". عليك أن تقول: "الآن في نيويورك ، يتم استخدام PST كوقت قياسي."
إذن ما الذي يجب أن نستخدمه بدلاً من الإزاحة لتحديد المنطقة الزمنية لمنطقة معينة؟ اسم هذه المنطقة. بتعبير أدق ، يجب عليك تجميع المناطق التي ينتقلون فيها بالتساوي إلى التوقيت الصيفي والتوقيت القياسي في منطقة زمنية واحدة. يمكنك استخدام أسماء مثل PT (توقيت المحيط الهادئ) ، لكنها تجمع فقط بين الوقت القياسي الحالي والوقت الصيفي ، ولا تأخذ بالضرورة في الاعتبار جميع التغييرات التاريخية. علاوة على ذلك ، نظرًا لأن PT يتم تداولها في الولايات المتحدة الأمريكية وكندا فقط ، فأنت بحاجة إلى الاعتماد على المعايير المعمول بها في المنظمات ذات السمعة الطيبة لضمان عالمية البرامج الخاصة بك.
قاعدة بيانات المنطقة الزمنية IANA
يجب أن أعترف أن المعلومات حول المناطق الزمنية هي بالأحرى قاعدة بيانات ، وليست مجموعة من القواعد ، لأن هذه المعلومات يجب أن تحتوي على جميع التغييرات التاريخية ذات الصلة. هناك العديد من قواعد البيانات القياسية المصممة لحل المهام المتعلقة بالمناطق الزمنية. في معظم الأحيان ،
يتم استخدام قاعدة بيانات المنطقة الزمنية IANA ، وعادة ما تسمى قاعدة بيانات tz (أو tzdata). تحتوي قاعدة البيانات على بيانات تاريخية عن التغييرات في الوقت القياسي و DST في جميع أنحاء العالم. علاوة على ذلك ، يتم تنظيمه بحيث يكون من الممكن التحقق من جميع البيانات التاريخية والتأكد من أن الوقت دقيق ابتداء من وقت يونكس (
1970.01/01 00:00:00 ). على الرغم من أنه يمكنك العثور على معلومات في قاعدة البيانات حتى قبل عام 1970 ، إلا أن دقتها غير مضمونة.
يستخدم اصطلاح التسمية قاعدة المنطقة / المكان. يستخدم عادة اسم القارة أو المحيط (آسيا ، أمريكا ، المحيط الهادئ) كمنطقة ، وأسماء المدن الرئيسية (سيول ، نيويورك) كمكان. والسبب هو أن المدن عادة ما تستمر لفترة أطول من البلدان. على سبيل المثال ، المنطقة الزمنية لكوريا الجنوبية هي
Asia/Seoul Asia/Tokyo . على الرغم من أن كلا البلدين يستخدمان نفس إزاحة
UTC+09:00 ، فقد تغير التوقيت المحلي بشكل مختلف ، لذا تم تقسيمهما إلى مناطق زمنية مختلفة.
تتم إدارة قاعدة IANA بواسطة العديد من مجتمعات المطورين والمؤرخين. يتم إدخال البيانات القديمة التي تم العثور عليها حديثًا على الفور ويتم تحديث السياسات الحالية ، لذلك يمكن اعتبار قاعدة البيانات اليوم المصدر الأكثر موثوقية. علاوة على ذلك ، يتم استخدامه تحت الغطاء بواسطة العديد من أنظمة Unix ، بما في ذلك Linux و MacOS ، بالإضافة إلى عدد من لغات البرمجة الشائعة ، بما في ذلك Java و PHP.
يرجى ملاحظة أن ويندوز يستخدم
قاعدة بيانات Microsoft . ومع ذلك ، فهي غير دقيقة من حيث البيانات التاريخية وتدعمها فقط مايكروسوفت نفسها. لذلك ، فإن القاعدة أقل موثوقية من قاعدة IANA.
جافا سكريبت و IANA
يتم تنفيذ وظيفة المنطقة الزمنية ذات الصلة في جافا سكريبت من اللون الأزرق. بشكل افتراضي ، تستخدم اللغة حزام المنطقة الحالي (بشكل أكثر دقة ، الحزام المحدد أثناء تثبيت نظام التشغيل) ، وليس هناك طريقة لتغييره. علاوة على ذلك ، فحتى مواصفات معيار قاعدة البيانات في جافا سكريبت غامضة ، وسوف تفهم ذلك بنفسك إذا قررت التعامل مع مواصفات ES2015. حول المنطقة الزمنية المحلية وتوافر التوقيت الصيفي ، هناك فقط بضع عبارات غامضة. على سبيل المثال ، يتم تعريف التوقيت الصيفي على النحو التالي:
ECMAScript 2015 - Daylight Saving Time Adjustment .
هذه خوارزمية تعتمد على التطبيق وتستخدم أفضل معلومات المنطقة الزمنية المتاحة لتحديد إعداد التوقيت الصيفي المحلي (t) DaylightSavingTA ، والذي يتم حسابه بالمللي ثانية. يجب أن يساعدك تطبيق ECMAScript على تحديد إعداد التوقيت الصيفي المحلي بشكل أفضل.
يبدو أنهم يقولون فقط ، "يا رجال ، حاولوا الحصول على هذا العمل". من بين أمور أخرى ، عليك حل مشكلة التوافق مع متصفحات مختلفة. أنت تقول ، "يا لها من فوضى!" ثم اقرأ السطر التالي:
ملاحظة: نوصي باستخدام المعلومات من قاعدة بيانات المنطقة الزمنية IANA http://www.iana.org/time-zones/ في تطبيقاتك.
نعم تمنحك مواصفات ECMA الكرة مع هذه التوصية البسيطة لاستخدام قاعدة بيانات IANA ، لأن JavaScript لا يحتوي على قاعدة بيانات قياسية خاصة. نتيجة لذلك ، تستخدم متصفحات مختلفة عملياتها الخاصة مع مناطق زمنية ، والتي غالباً ما تكون غير متوافقة مع بعضها البعض ، لحساب الوقت. في وقت لاحق ، في ECMA ، لواجهة برمجة التطبيقات الدولية ، تمت إضافة خيار استخدام بيانات IANA بتنسيق ECMA-402
Intl.DateTimeFormat . ولكن هذا الخيار أقل موثوقية بكثير من نظائرها في لغات البرمجة الأخرى.
المنطقة الزمنية في بيئة الخادم والعميل
النظر في سيناريو بسيط: نحن بحاجة إلى تحديد المنطقة الزمنية. لنفترض أننا نقوم بإنشاء تقويم سيعالج معلومات الوقت. عندما يقوم مستخدم في بيئة العميل بإدخال التاريخ والوقت في نافذة التسجيل ، يتم نقل التاريخ إلى الخادم وتخزينه في قاعدة البيانات. ثم يتلقى العميل من الخادم التاريخ المسجل في الجدول الزمني للعرض على الشاشة.
هنا تحتاج إلى أن تقرر شيئا. ماذا لو كان بعض العملاء الذين يصلون إلى الخادم في مناطق زمنية مختلفة؟ يجب عرض الحدث في الجدول ، الذي تم تسجيله في سيول في 10 مارس 2017 الساعة 23.30 ، في نيويورك في 10 مارس 2017 الساعة 9.30. لكي يخدم الخادم العملاء من مناطق زمنية مختلفة ، يجب أن يحتوي الجدول المخزن على قيم مطلقة لا تعتمد على المنطقة. لكل خادم طريقته الخاصة لتخزين هذه القيم ، هذا السؤال هو خارج نطاق المقال ، لأن كل شيء يعتمد على خادم أو قاعدة بيانات محددة. بشكل عام ، يجب تقديم التاريخ والوقت المنقولين من العميل إلى الخادم إما في شكل قيم تستند إلى إزاحة واحدة (عادةً UTC) أو في شكل قيم تحتوي على معلومات حول المنطقة الزمنية لبيئة العميل.
عادةً ما يتم إرسال هذه البيانات
وقت يونكس بتنسيق UTC أو وفقًا
لمعيار ISO-8601 مع معلومات الإزاحة. إذا قمنا في مثالنا بتحويل Seoul 21.30 في 10 مارس 2017 إلى وقت Unix ،
1489113000 قيمة عدد صحيح
1489113000 . وفي تنسيق ISO-8601 ، تكون قيمة السلسلة هي
2017–03–10T11:30:00+09:00 .
إذا كنت تستخدم JavaScript في بيئة مستعرض ، فيجب عليك تحويل القيمة التي تم إدخالها كما هو موضح أعلاه ، ثم تحويلها مرة أخرى لمطابقة المنطقة الزمنية للمستخدم. من الضروري حل كل من هذه المشاكل. من وجهة نظر لغة البرمجة ، تسمى العملية الأولى "تحليل" ، والثانية هي "التنسيق". الآن دعونا نرى كيف يتم ذلك في جافا سكريبت.
حتى عند العمل مع JS في بيئة خادم باستخدام Node.js ، فقد تحتاج إلى تحليل البيانات الواردة من العميل. ولكن نظرًا لأن المناطق الزمنية للخوادم وقواعد البيانات عادة ما تكون متزامنة ، ويتم تعيين التنسيق للعملاء ، في بيئة متصفح تحتاج إلى اتخاذ قرار بشأن عدة عوامل. كذلك سأشرح فيما يتعلق ببيئة المتصفح.
كائن تاريخ JavaScript
يتم حل المهام التي تنطوي على العمل مع وقت أو وقت معين باستخدام كائن
Date . هذا كائن أصلي معرف في ECMAScript ، مثل
Array أو
Function . وهذا هو ، بالنسبة للجزء الأكبر ، يتم تنفيذها باستخدام رمز الأصلي مثل C ++. يتم وصف API بشكل جيد في
وثائق MDN . كان لفئة
java.util.Date من Java تأثير كبير على الكائن ، لذا فقد ورثت بعض الخصائص غير المرغوب فيها ، مثل خصائص البيانات القابلة للتغيير وشهر يبدأ من الصفر.
تحت الغطاء ، يعمل كائن JavaScript على الوقت باستخدام القيم المطلقة بتنسيق وقت Unix. لكن
getHour() والأساليب مثل وظائف
getHour() parse() ،
getHour() ،
setHour() وغيرها تتأثر بالمنطقة الزمنية للعميل (بشكل أكثر دقة ، الحزام المحدد في نظام التشغيل الذي يعمل فيه المتصفح). لذلك إذا قمت بإنشاء كائن "
Date مباشرةً باستخدام البيانات التي أدخلها المستخدم ، فسوف تنعكس المنطقة الزمنية المحلية للعميل في هذه البيانات.
كما ذكرت ، لا يوفر JavaScript أي طريقة لتغيير المنطقة الزمنية بشكل تعسفي. لذلك ، نفترض أنه يمكننا استخدام قيمة المنطقة الزمنية المحددة في المتصفح مباشرةً.
إنشاء كائن تاريخ باستخدام إدخال المستخدم
دعنا نعود إلى المثال الأول. لنفترض أن مستخدمًا قام بإدخال وقت سيئول على جهازه في الساعة 11.30 يوم 11 مارس 2017. يتم حفظ هذه البيانات في خمسة أرقام: 2017 ، 2 ، 11 ، 11 و 30 سنة ، شهر ، يوم ، ساعات ودقائق ، على التوالي (منذ أن يبدأ الشهر في 0 ، يجب أن تكون القيمة 3-1 = 2). باستخدام المنشئ ، يمكنك بسهولة إنشاء كائن
Date :
const d1 = new Date(2017, 2, 11, 11, 30); d1.toString();
إذا نظرت إلى القيمة التي يتم إرجاعها بواسطة
d1.toString() ، سترى أن القيمة المطلقة للكائن الذي تم إنشاؤه هي 11:00 في 11 مارس 2017 ، تم حسابها باستخدام
+09:00 (KST).
يمكنك استخدام بيانات السلسلة في المنشئ. إذا قمت بتطبيقها على
Date ، فإن الكائن يستدعي
Date.parse() داخليًا
Date.parse() القيمة الصحيحة. تدعم هذه الميزة
مواصفات RFC2888 و
ISO-8601 . لكن
وثائق MDN الخاصة بـ Date.parse () تقول أن القيمة التي يتم إرجاعها بواسطة هذه الطريقة تعتمد على المستعرض ، ويمكن أن يؤثر تنسيق نوع السلسلة على القيمة النهائية الدقيقة. لذلك ، من الأفضل عدم استخدام هذه الطريقة. على سبيل المثال ، في Safari و Internet Explorer ، تُرجع قيمة السلسلة مثل
2015–10–12 12:00:00 NaN ، بينما في Chrome و Firefox تُرجع المنطقة الزمنية المحلية. في بعض الحالات ، يتم إرجاع قيمة تستند إلى UTC.
إنشاء كائن تاريخ باستخدام بيانات الخادم
افترض أنك تريد تلقي بيانات من خادم. إذا كانت في شكل وقت Unix رقمي ، فيمكنك ببساطة استخدام المنشئ لإنشاء كائن
Date . لم أذكر بعد أنه عندما يتلقى مُنشئ
Date قيمة واحدة كمعلمة فردية ، فإنه يحسب قيمة وقت يونكس بالمللي ثانية (ملاحظة: JS يعالج وقت يونكس بالمللي ثانية. وهذا يعني أنه يجب ضرب القيمة الثانية ب 1000). عند تنفيذ الكود التالي ، نحصل على نفس القيمة كما في المثال السابق:
const d1 = new Date(1489199400000); d1.toString();
وإذا بدلاً من وقت يونكس ، استخدم نوع السلسلة ISO-8601؟ كما شرحت أعلاه ، فإن طريقة
Date.parse() تصبح غير موثوقة ومن الأفضل عدم استخدامها. ومع ذلك ، بدءًا من ECMAScript 5 ، يمكنك استخدام إنشاءات السلسلة في تنسيق ISO-8601 في مُنشئ
Date في Internet Explorer 9.0 والإصدارات الأحدث.
إذا كنت لا تستخدم أحدث متصفح ، فتأكد من أن
Z في نهاية القيم. بدون ذلك ، يمكن للمستعرض القديم الخاص بك تفسير القيمة بناءً على التوقيت المحلي ، وليس التوقيت العالمي المنسق. فيما يلي مثال للاستخدام في Internet Explorer 10:
const d1 = new Date('2017-03-11T11:30:00'); const d2 = new Date('2017-03-11T11:30:00Z'); d1.toString();
وفقًا للمواصفات ، في كلا الحالتين يجب الحصول على نفس القيمة. لكنهم مختلفون. في متصفح لاحق ، فإن القيم ستكون هي نفسها. لمنع هذه المشكلة ، قم دائمًا بإضافة
Z في نهاية السطر إذا كانت معلومات المنطقة الزمنية غير متوفرة.
إنشاء تاريخ لتمرير إلى الخادم
يمكنك الآن استخدام
Date تم إنشاؤه مسبقًا ، واسترجاع أو إضافة الوقت بحرية استنادًا إلى مناطق التوقيت المحلية. في نهاية المعالجة فقط ، لا تنسَ تحويل البيانات إلى التنسيق السابق قبل إعادتها إلى الخادم.
إذا كان هذا وقت يونكس ، فيمكنك استخدام الأسلوب
getTime() (لا تنس بالمللي ثانية).
const d1 = new Date(2017, 2, 11, 11, 30); d1.getTime();
ماذا عن قيمة السلسلة بتنسيق ISO-8601؟ كما قلت ، يدعم Internet Explorer 9.0 والإصدارات الأحدث ECMAScript 5 ، والإصدارات الأحدث تدعم ISO-8601. لذلك ، باستخدام أساليب
toISOString() أو
toJSON() ، يمكنك إنشاء سلسلة في ISO-8601 (
toJSON() يمكن استخدامها للمكالمات المتكررة مع
JSON.stringify() وغيرها). تعطي كلتا الطريقتين نفس النتيجة ، إلا عند معالجة بيانات غير صالحة:
const d1 = new Date(2017, 2, 11, 11, 30); d1.toISOString();
يمكنك استخدام أساليب
toGMTString() أو
toUTCString() لإنشاء سلسلة UTC. سينتج عن ذلك قيمة تتوافق مع
RFC-1123 .
يتضمن كائن
Date toString() ،
toLocaleString() وطرق الامتداد الخاصة بها. ولكنها ذات فائدة قليلة ، حيث يتم استخدامها بشكل رئيسي لإرجاع السلاسل استنادًا إلى المنطقة الزمنية المحلية ، وتعتمد القيم التي يتم إرجاعها على المستعرض ونظام التشغيل.
تغيير المنطقة الزمنية المحلية الخاصة بك
كما ترون ، هناك نوع من دعم المنطقة الزمنية في JS. ? ? , JS . , . . , .
. . 11.30 11 2017 - . Unix- , -
-05:00 . , .
getTimeZoneOffset() . API JavaScript, . :
const seoul = new Date(1489199400000); seoul.getTimeZoneOffset();
-540 , 540 . , (
+09:00 ). , , . -,
60 * 5 = 300 .
840 Date .
getXX . :
function formatDate(date) { return date.getFullYear() + '/' + (date.getMonth() + 1) + '/' + date.getDate() + ' ' + date.getHours() + ':' + date.getMinutes(); } const seoul = new Date(1489199400000); const ny = new Date(1489199400000 - (840 * 60 * 1000)); formatDate(seoul);
formatDate() -. , . , ? , . , — , . ( ).
, . , -, 11 15 .
setDate() Date , , .
ny.setDate(15); formatDate(ny);
, . , ? ,
getTime() getISOString() . , .
const time = ny.getTime() + (840 * 60 * 1000);
, , .
Date ? رقم
Date 11- 15-, 4 (
24 * 4 * 60 * 60 * 1000 ). - 10- 15-, 5 (
24* 5 * 60 * 60 * 1000 ). .
. , . - 12 , 15 2017
-04:00 ,
-05:00 . , 780 , 60 , .
const time = ny.getTime() + (780 * 60 * 1000);
, - , .
, . , , , . , ,
IANA .
,
Date , . , . , . . JS . .
Moment Timezone
Moment — JavaScript-, . API , .
Moment Timezone , . IANA API, .
. , .
.
, Moment Timezone:
const seoul = moment(1489199400000).tz('Asia/Seoul'); const ny = moment(1489199400000).tz('America/New_York'); seoul.format();
seoul ,
ny -05:00 -04:00 .
format() , ISO-8601, . .
الخاتمة
API , JavaScript, . , API, Internet Explorer 9 . , . ,
getTimezoneOffset() . , . Moment Timezone.
, , . : . , , , . , JavaScript . , .
روابط مفيدة