محوّل الطابع الزمني
حوّل طابع Unix الزمني إلى تاريخ مقروء والعكس. تحصل على الثواني والميلي ثانية وISO 8601 وUTC والتوقيت المحلي واليوم والأسبوع وصيغة RFC 2822 ووقت نسبي مثل «قبل
حوّل بين طوابع Unix الزمنية والتواريخ المقروءة، في الاتجاهين وبالثواني والميلي ثانية. الصق 1735689600 أو 2026-01-01T00:00:00Z لترى المقابل بتوقيت UTC وبتوقيت منطقتك المحلية وبصيغ شائعة مثل ISO 8601 وRFC 2822.
وهذا يتكرر باستمرار عند قراءة السجلات، أو تتبّع خطأ في واجهة API تعيد ثواني epoch، أو التأكد من أن انتهاء صلاحية رمز ما هو كما تظن. والتحويل دقيق ويجري محلياً، وينبّهك عندما تبدو القيمة بالميلي ثانية لا بالثواني.
كيفية تحويل طابع Unix الزمني
الصق طابعاً زمنياً أو تاريخاً
اقرأ القيم المحوّلة بتوقيت UTC والتوقيت المحلي
انسخ الصيغة التي تحتاجها
الأسئلة الشائعة
ثوانٍ أم ميلي ثانية؟
عشرة أرقام تعني عادةً ثوانٍ، وثلاثة عشر رقماً تعني عادةً ميلي ثانية. وتكتشف الأداة الوحدة المرجّحة وتتيح لك تبديلها إن بدت النتيجة خاطئة.
ما هي حقبة Unix؟
عدد الثواني منذ 1 يناير 1970 الساعة 00:00:00 بتوقيت UTC، دون احتساب الثواني الكبيسة. وهي الطريقة القياسية لتخزين لحظة زمنية.
أي منطقة زمنية تُستخدم؟
يُعرض الاثنان: توقيت UTC والمنطقة الزمنية المحلية لمتصفحك، فتقارن بين ما تسجّله سجلات الخادم وما تراه على الساعة.
هل يتعامل مع تواريخ قبل 1970؟
نعم، القيم السالبة تمثّل تواريخ قبل الحقبة، والتواريخ البعيدة في المستقبل تعمل إلى حدود نطاق التواريخ في JavaScript.
هل يمكنه إنتاج طابع زمني لتاريخ معيّن؟
نعم، فالتحويل يعمل في الاتجاهين - أدخل تاريخاً لتحصل على قيمة epoch.
هل يُرفع أي شيء إلى خادم؟
لا، التحويل عملية حسابية محلية.
نظرة سريعة
| المدخل | نص |
|---|---|
| عدة ملفات | لا |
| مكان التشغيل | في متصفحك، ولا تُرفع الملفات أبداً |
| يعمل دون اتصال | نعم — بعد تحميل الصفحة |
| السعر | مجاني، بلا تسجيل وبلا علامة مائية |
أين تنكسر التحويلات بهدوء
معظم أخطاء التحويل لا تتعلق بالصياغة بل بالمعنى. فعمود من الرموز البريدية في ملف CSV يفقد أصفاره البادئة في اللحظة التي يخمّن فيها جدول البيانات أنه رقم؛ ومعرّف طويل يتجاوز دقة الفاصلة العائمة؛ والتواريخ يتغير معناها بحسب ما إذا كان اليوم أولاً أم الشهر أولاً. ومفاتيح JSON غير مرتبة أما المصفوفات فمرتبة، والأداة التي ترتب المفاتيح لا تغيّر شيئاً بينما التي ترتب المصفوفات تغيّر البيانات. وUnicode فخ آخر: فقد يصل النص بترميز UTF-8 أو UTF-16 أو مع علامة ترتيب البايتات، وفاكّ الترميز الذي يخمّن خطأً يحوّل المحارف المشكّلة إلى نص مشوّه. وقبل أن تثق بأي تحويل، افحص الصف الأول والأخير، وكل حقل فيه أصفار بادئة، وكل حقل يحتوي على علامات تنصيص أو فواصل أو أسطر جديدة.
اختيار صيغة البيانات
JSON هو الصيغة الافتراضية لكل ما تُرجعه واجهة API أو يقرأه برنامج: فهو يتعامل بطبيعته مع البنى المتداخلة والأرقام والقيم المنطقية وnull، وكل لغة تحلّله. أما CSV فأصغر حجماً ويُفتح مباشرة في جدول بيانات، لكنه لا يملك وسيلة للتعبير عن التداخل ولا معياراً مشتركاً للفاصل أو التنصيص أو مجموعة المحارف، وهذا بالضبط موضع الخطأ في التحويلات. أما XML فمطوّل لكنه يحمل السمات والمحتوى المختلط والمخططات، ولذلك ما زال مهيمناً على صيغ المستندات والتكاملات القديمة. وYAML هو الأسهل قراءةً في الإعدادات لكنه حساس للمسافات البيضاء وفيه إكراه مفاجئ للأنواع («no» تصبح false، وإصدار مثل 1.10 يصبح 1.1). فاختر الصيغة التي تفضّلها الأداة المستهلكة لا الصيغة الأجمل منظراً.