هذا ليس شيئًا خاصًا بالزاوية. إنه السلوك القياسي JSON.stringify .

بشكل أساسي ، عند نشر البيانات ، يقوم $http بتحويلها إلى JSON (عبر JSON.stringify() ). في JavaScript ، تمثيل JSON لكائن التاريخ هو شكله ISO-8601 (وهو ما تراه في علامة تبويب الشبكة).

لا يحتوي كائن التاريخ على معلومات المنطقة الزمنية على أي حال ، لذلك لا توجد معلومات مجردة. يحتوي الموقع الحالي (وهو مستقل تمامًا عن التاريخ الذي تمثله كائنات التاريخ) على إزاحة المنطقة الزمنية وينسق المتصفح التاريخ وفقًا لذلك الإزاحة عند console.log ging.

إغلاق لأن هذه ليست مشكلة مع Angular.

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

new Date().getTimezoneOffset()
-330

new Date().toISOString()
"2018-12-04T05:40:37.399Z"

ثانيًا ، JSON.stringify() أيضًا لا يزيل قيمة المنطقة ، ما يلي هو ما رأيناه في وحدة تحكم المتصفح وهو نفسه ، المتصفح لا يطبع أي شيء لطيف بالنسبة لنا.

JSON.stringify({d:new Date()})
"{"d":"2018-12-04T05:42:08.973Z"}"

لذلك ما زلت أعتقد أنه إذا عرضت واجهة برمجة التطبيقات تاريخ ISO لا يحتوي على تلك القيمة بالمللي ثانية وكانت واجهة المستخدم تستخدم بعض منتقي البيانات الذي لا يختار سوى التاريخ وتاريخ التغيير ، فإن Angular عند إرسال التاريخ مرة أخرى وتحويله إلى تنسيق ISO لن يكون لها مللي ثانية القيمة.

أولاً ، أعتقد أنه ليس من الصحيح قول أن كائن التاريخ لا يحتوي على معلومات المنطقة الزمنية.

ما زلت أعتقد أنه من الصحيح أن أقول: ابتسامة: A Date object _ "يمثل لحظة واحدة في الوقت [...] استنادًا إلى قيمة زمنية تمثل عدد المللي ثانية منذ 1 كانون الثاني (يناير) 1970 بالتوقيت العالمي المنسق" _ (المصدر: MDN ). لذلك ، في الأساس ، يعرف كل مثيل Date هذه القيمة الواحدة فقط ويتم إنشاء جميع التمثيلات الأخرى لها بناءً على تلك المعلومات بالإضافة إلى الحالة المحلية / حالة النظام (مثل إزاحة المنطقة الزمنية).

#

كائن التاريخ له أساليب getTimezoneOffset و toISOString .

هذه توابع على النموذج الأولي Date (المصدر: MDN ) ، وليس كائنات Date (الملقب بالمثيلات) نفسها.

وبشكل أكثر تحديدًا ، تعتمد قيمة getTimezoneOffset () على الإعدادات المحلية الحالية (إعدادات النظام المضيف). هذا هو السبب في عدم وجود طريقة setTimezoneOffset() مكافئة ولماذا تقوم جميع الكائنات Date في نفس النظام بإرجاع نفس القيمة لـ getTimezoneOffset() ، على سبيل المثال:

const d1 = new Date('December 15, 2018 12:34:56');  // No timezone; uses the current system locale.
const d2 = new Date('December 15, 2018 12:34:56 GMT+10'); // Uses GTM+10 as timezone.

d1.getTimezoneOffset() === d2.getTimezoneOffset();  // true

لذلك ، فإن معلومات المنطقة الزمنية المحددة في تمثيل سلسلة التاريخ التي تم تمريرها إلى Date تُستخدم فقط لتحليل هذه السلسلة وتعيينها إلى لحظة محددة في الوقت كما هو موضح أعلاه. لا يعرف الكائن Date الناتج أي شيء عن المناطق الزمنية: مبتسم:

لا تطبع طريقة toISOString () معلومات المنطقة الزمنية كما اقترحت. إنها تضيف فقط Z في النهاية ، مما يدل على UTC .

#

ثانيًا ، لا يزيل أيضًا JSON.stringify() قيمة المنطقة

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

#

لذلك ما زلت أعتقد أنه إذا عرضت واجهة برمجة التطبيقات تاريخ ISO لا يحتوي على تلك القيمة بالمللي ثانية وكانت واجهة المستخدم تستخدم بعض منتقي البيانات الذي لا يختار سوى التاريخ وتاريخ التغيير ، فإن Angular عند إرسال التاريخ مرة أخرى وتحويله إلى تنسيق ISO لن يكون لها مللي ثانية القيمة.

ليس لدي أي فكرة عما يجب أن تفعله أجزاء من الثانية. كنا نتحدث عن معلومات المنطقة الزمنية.

مرة أخرى ، هذا لا علاقة له بـ AngularJS. هذه هي الطريقة التي تتفاعل بها الكائنات المضمنة (مثل Date و JSON ) مع بعضها البعض.