الثواني مقابل الميلي ثانية
1777118400
1777118400000
كلتا القيمتين تصفان اللحظة نفسها إذا فُسّرت الأولى بالثواني والثانية بالميلي ثانية. الخلط بينهما من أكثر أخطاء الطوابع الزمنية شيوعًا.
حوّل بين طوابع Unix وISO 8601 وUTC والوقت المحلي.
Last updated
177724005017772400500002026-04-26T21:47:30.000Z2026-04-26 21:47:30Sun, 26 Apr 2026 21:47:30 GMTمحوّل الطابع الزمني Unix يحوّل *وقت Epoch* — أي رقم واحد يمثّل لحظة بعينها — إلى تاريخ مقروء، ويعيد تحويل التواريخ إلى أرقام. المطوّر يصادف الطوابع الزمنية في كل مكان: أعمدة قواعد البيانات، سطور السجلات، استجابات الـ APIs، أحداث التحليلات، حقل exp في JWT، مشغّلات الجدولة، وترويسات انتهاء الكاش.
الفكرة بسيطة: الحاسوب يخزّن الوقت كرقم (ثوانٍ أو ميلي ثانية منذ 1970-01-01 00:00:00 UTC)، لكن البشر يحتاجون تقاويم ومناطق زمنية وصيغًا مقروءة. التحويل بين الاثنين من أكثر مهام التنقيح شيوعًا في أي تطبيق ويب أو موبايل.
أكثر نقطة تربك المطوّرين هي *الوحدة*. POSIX ومعظم لغات الـ backend تستخدم الثواني. JavaScript و Java وعدد من وسطاء الرسائل يستخدمون الميلي ثانية. بعض أنظمة المقاييس تستخدم ميكرو ثانية أو نانو ثانية. الرقم المكوّن من 10 خانات يكون غالبًا بالثواني، والمكوّن من 13 خانة يكون غالبًا بالميلي ثانية.
1970-01-01 00:00:00 UTC).2026-04-25T12:00:00Z) تنسيق نصّي قابل للنقل. حرف Z (أو +00:00) في النهاية يعني UTC، بينما إزاحة مثل +02:00 تعني توقيتًا محليًا يسبق UTC بساعتين.ألصق رقمًا (بالثواني أو الميلي ثانية) أو سلسلة تاريخ. المحوّل يكتشف الصيغة تلقائيًا اعتمادًا على طول الرقم وشكله.
بدّل بين الثواني والميلي ثانية إذا أخطأ الاكتشاف التلقائي — الرقم ذو 10 خانات بالثواني، وذو 13 خانة بالميلي ثانية.
تظهر النتيجة بصيغة ISO 8601 بتوقيت UTC، وبتوقيتك المحلي، وبعبارة نسبية مقروءة (قبل 3 ساعات، بعد يومين).
انسخ الطابع الزمني أو سلسلة ISO أو التوقيت المحلي مباشرة. مفيد عند تعبئة حقل exp في JWT أو سجل في قاعدة بيانات أو استعلام بحث في السجلات.
أكثر الصيغ التي ستراها عند التعامل مع التواريخ والأوقات في الكود. صيغة ISO 8601 معتمدة أيضًا من IETF عبر RFC 3339 للاستخدام في البروتوكولات.
| الصيغة | مثال | أين تصادفها |
|---|---|---|
| Unix بالثواني | 1777118400 | سجلات الـ backend، حقل exp في JWT، دالة time() في POSIX، Redis |
| Unix بالميلي ثانية | 1777118400000 | Date.now() في JavaScript وSystem.currentTimeMillis() في Java |
| ISO 8601 بتوقيت UTC | 2026-04-25T12:00:00Z | REST APIs و JSON و GraphQL وملفات السجلات |
| ISO 8601 مع إزاحة | 2026-04-25T14:00:00+02:00 | جدولة الأحداث الموجّهة للمستخدم، دعوات التقويم |
| RFC 2822 | Sat, 25 Apr 2026 12:00:00 GMT | ترويسات البريد الإلكتروني، ترويسات HTTP مثل Date و Last-Modified |
| تاريخ فقط | 2026-04-25 | أعياد الميلاد والمناسبات — بدون أي دلالة على المنطقة الزمنية |
1777118400
1777118400000
كلتا القيمتين تصفان اللحظة نفسها إذا فُسّرت الأولى بالثواني والثانية بالميلي ثانية. الخلط بينهما من أكثر أخطاء الطوابع الزمنية شيوعًا.
{ "id": 42, "createdAt": 1777118400, "expiresAt": 1777204800}حوّل كل قيمة قبل أن تفترض إن كانت في الماضي أو في المستقبل. معظم واجهات JSON تستخدم Unix بالثواني، لكن راجع التوثيق دائمًا — كثير من الـ backends المبنية على JavaScript تُرجع الميلي ثانية.
2026-04-25T12:00:00Z
2026-04-25T14:00:00+02:00
السلسلتان تمثّلان *اللحظة ذاتها*. خزّن اللحظات دائمًا بـ UTC، ولا تنسّقها للتوقيت المحلي إلا عند العرض.
1700000000 إذا قُرئ كثوانٍ يكون نوفمبر 2023، وإذا قُرئ كميلي ثانية يصبح يناير 1970.'2026-04-25') بدلًا من مقارنة الطوابع الزمنية. سلسلتان ISO صحيحتان قد تصفان اللحظة نفسها بصيغتين مختلفتين.1970-01-01 00:00:00 UTC. هو رقم واحد يمثّل لحظة محدّدة في الزمن، مستقلًا عن أي منطقة زمنية.Date.now() في JavaScript تُرجع ميلي ثانية، بينما معظم الـ backends تُرجع ثوانٍ.Date في JavaScript يخزّن الطوابع الزمنية كميلي ثانية منذ بداية حقبة Unix — وهذه القيمة التي تُرجعها Date.now() وnew Date().getTime(). تمنح دقة أعلى من الثواني، لكنها مصدر متكرّر لأخطاء الفرق بـ 1000 عند التواصل مع لغات أخرى.new Date(...) في JavaScript، أو استخدم datetime.fromtimestamp(...) في Python. أو ألصقها في محوّل طابع Unix الزمني للحصول على النتيجة بنقرة واحدة.2038-01-19 — ما يُعرف بمشكلة عام 2038. اللغات وقواعد البيانات الحديثة تخزّن الطوابع كأعداد صحيحة بـ 64 بت، ما يمدّد المدى الآمن لمئات المليارات من السنين.