مقدمة
يساعدك هذا المحول على فحص وقت Unix بسرعة من داخل المتصفح. يمكنك رؤية الوقت الحالي وقيم epoch التي تتحدث كل ثانية، وتحويل طابع زمني موجود إلى وقت محلي وUTC بصيغة مقروءة، ثم تحويل تاريخ تختاره مرة أخرى إلى ثواني أو ميلي ثواني Unix من أجل واجهات API أو السجلات أو قواعد البيانات أو جلسات التصحيح.
طريقة الاستخدام
ابدأ بلوحة الوقت المباشر لمقارنة اللحظة الحالية مع قيم epoch المقابلة لها. في قسم التحويل من epoch إلى تاريخ، ألصق قيمة الطابع الزمني وحدد هل هي بالثواني أم بالميلي ثانية. ستظهر لك فوراً الساعة المحلية وUTC وISO 8601 واليوم والفارق النسبي عن الوقت الحالي. في قسم التحويل من تاريخ إلى epoch، اختر تاريخاً ووقتاً محليين لتحصل على ثواني وميلي ثواني Unix. يتم تفسير إدخال التاريخ وفق المنطقة الزمنية الحالية لجهازك.
الميزات
- •عرض الوقت الحالي وثواني epoch وميلي ثوانيه مع تحديث كل ثانية
- •تحويل epoch إلى وقت محلي وUTC وISO 8601 واليوم والوقت النسبي
- •تحويل التاريخ والوقت المحليين مرة أخرى إلى ثواني وميلي ثواني Unix
- •مفيد لواجهات API والسجلات والتحقق من JWT والمهام المجدولة وتصحيح قواعد البيانات
- •المعالجة تتم محلياً داخل المتصفح من دون رفع البيانات إلى خادم
لماذا يهم التفريق بين الثواني والميلي ثانية
يظهر وقت Unix عادة بوحدتين شائعتين: الثواني والميلي ثانية. كثير من واجهات API ومطالبات JWT والحمولات الخلفية تستخدم الثواني، بينما يستخدم JavaScript Date.now() وكثير من أدوات المتصفح الميلي ثانية. إذا بدا التاريخ بعيداً جداً في الماضي أو المستقبل، فالسبب الأكثر شيوعاً هو اختيار الوحدة الخاطئة.
سيناريوهات استخدام شائعة
يفيد هذا النوع من التحويل عند قراءة سجلات التطبيقات، وفحص أوقات الانتهاء، والتحقق من الجدولة، ومراجعة أحداث التحليلات، ومقارنة ساعة الواجهة الأمامية مع ساعة الخادم. كما يساعدك على معرفة ما إذا كان حقل قاعدة البيانات يخزن epoch بالثواني أو بالميلي ثانية أو سلسلة ISO جاهزة.
الوقت المحلي مقابل UTC
يعتبر UTC المرجع الأكثر ثباتاً عندما يعمل المستخدمون والخوادم والفرق في مناطق زمنية مختلفة. ومع ذلك يظل الوقت المحلي مهماً لأنه يوضح ما رآه المستخدم أو الجهاز فعلياً. عرض الاثنين معاً يقلل أخطاء الإزاحة والتوقيت الصيفي وافتراضات المنطقة الزمنية.
ماذا تفعل إذا بدا الناتج غير صحيح
تحقق أولاً هل القيمة بالثواني أم بالميلي ثانية، ثم هل يستخدم النظام المصدر UTC، ثم هل يجب تفسير الإدخال المحلي بمنطقة زمنية أخرى، وأخيراً هل ساعة الجهاز دقيقة. غالبية أخطاء الطوابع الزمنية تنكشف بهذه الخطوات.
أي نوع إدخال يجب أن تستخدمه؟
اختر المسار المناسب بحسب مصدر البيانات.
| نوع الإدخال | الأفضل من أجله | ملاحظة مهمة |
|---|---|---|
| Epoch بالثواني | مطالبات JWT وكثير من واجهات API ومخرجات Unix | إذا بدا التاريخ قديماً جداً فتحقق أولاً من أن المصدر لا يستخدم الميلي ثانية |
| Epoch بالميلي ثانية | قيم JavaScript Date وسجلات المتصفح وأحداث الواجهة | في التواريخ الحديثة تكون القيمة غالباً من 13 خانة تقريباً |
| تاريخ ووقت محليان | مراجعة الجدولة والفحص اليدوي ومراجعة قواعد البيانات | يتم تفسير الإدخال وفق المنطقة الزمنية الحالية للجهاز |
دليل حقول المخرجات
كل صيغة مخرجات تساعدك على الإجابة عن سؤال مختلف.
| المخرج | ما الذي يساعدك على فحصه | الاستخدام المعتاد |
|---|---|---|
| الوقت المحلي | كيف يظهر الوقت على هذا الجهاز | تقارير المستخدمين والمراجعات الإقليمية |
| UTC / ISO 8601 | مرجع محايد بالنسبة للمنطقة الزمنية | مقارنة الخوادم والسجلات والتصحيح المشترك |
| الوقت النسبي | كم يبعد الوقت عن الآن | الانتهاء والحداثة وفحوص الجدولة |
الأسئلة الشائعة
هل أستخدم الثواني أم الميلي ثانية مع Unix timestamp؟
استخدم الوحدة التي يتوقعها النظام المصدر. كثير من واجهات API ومطالبات JWT تستخدم الثواني، بينما قيم JavaScript Date تستخدم الميلي ثانية غالباً.
لماذا يبدو التاريخ المحول بعيداً جداً عن المتوقع؟
غالباً لأن الوحدة غير صحيحة. قراءة الثواني كأنها ميلي ثانية تعطي تاريخاً أقدم بكثير، وقراءة الميلي ثانية كأنها ثوانٍ تعطي تاريخاً أبعد بكثير في المستقبل.
هل يستخدم قسم تحويل التاريخ إلى epoch توقيت UTC؟
لا. يتم تفسير إدخال التاريخ والوقت المحليين وفق المنطقة الزمنية الحالية لجهازك ثم تحويله إلى وقت Unix.
لماذا يعرض الأداة UTC والوقت المحلي معاً؟
لأن UTC يوفر مرجعاً ثابتاً بين الأنظمة، بينما يساعدك الوقت المحلي على فهم ما شاهده المستخدم أو الجهاز فعلياً.
هل يتم رفع هذه القيم إلى خادم؟
لا. يعمل المحول محلياً داخل متصفحك وتبقى القيم على جهازك.