Unix Epoch Time Converter ومولد الطابع الزمني للخلاف

قم بتحويل الطوابع الزمنية لعصر Unix إلى تواريخ يمكن قراءتها بواسطة الإنسان والعكس صحيح. قم بإنشاء طوابع زمنية قابلة للنسخ واللصق في Discord في الوقت الفعلي.

طابع زمن يونكس الحالي
ثواني 0000000000
ملي ثانية 0000000000000
الوقت المحلي
-
التوقيت العالمي (UTC)
-
Unix Epoch (sec)
-
Unix Epoch (ms)
-
الوقت النسبي
-
مقارنة المناطق الزمنية بصرياً Slide this handle to synchronize and visually compare the local and UTC dates and times across all selected timezones in real time.

حرك المؤشر للمقارنة البصرية للوقت عبر مناطق زمنية متعددة.

-12h -6h UTC (0) +6h +12h

                                
                            

تتطلب مزامنة أنظمة قواعد البيانات الموزعة وتسجيل أحداث التطبيق وتصحيح أخطاء حمولات واجهة برمجة التطبيقات طريقة موحدة ودقيقة للغاية لتتبع الوقت. يوفر توحيد وقت عصر Unix عددًا صحيحًا غير قابل للتغيير ومستقل عن المنطقة الزمنية يمثل العدد الدقيق للثواني المنقضية منذ 1 يناير 1970. يوضح هذا الدليل الشامل تفاصيل آليات الطوابع الزمنية لنظام Unix، ويوضح طرق التحويل البرمجية عبر البيئات الحديثة، ويشرح كيفية تحليل بنيات زمنية بديلة مثل معرفات ندفة الثلج في Discord.

فهم وقت عصر يونكس وديناميكيات الطابع الزمني

يتتبع وقت Unix (المعروف أيضًا باسم عصر Unix أو وقت POSIX أو الطابع الزمني لـ Unix) التقدم الزمني كعدد صحيح متزايد. وهو يمثل عدد الثواني المنقضية منذ النقطة المرجعية 1 يناير 1970، الساعة 00:00:00 بالتوقيت العالمي (تمثيل ISO 8601: 1970-01-01T00:00:00Z). في نفس اللحظة من هذه الحقبة، كان العداد يقف عند 0 بالضبط.

الطوابع الزمنية للعصر مستقلة تمامًا عن المنطقة الزمنية. يمثل العدد الصحيح لحظة عالمية فريدة في جميع أنحاء العالم، وتقوم تطبيقات العميل المحلي بضبط طبقة العرض التقديمي من خلال تطبيق إزاحات UTC محددة. لمعرفة كيفية عمل تعيين المنطقة الزمنية، قارن التفسيرات المحلية للطابع الزمني 1577923200:

المنطقة الزمنية التاريخ والوقت المحلي قيمة الإزاحة
بتوقيت جرينتش / التوقيت العالمي المنسق الخميس 2 يناير 2020، 00:00:00 التوقيت العالمي +00:00
الهند (كولكاتا) الخميس 2 يناير 2020 الساعة 05:30:00 التوقيت العالمي +05:30
أمريكا (نيويورك) الأربعاء 1 يناير 2020 الساعة 19:00:00 التوقيت العالمي المنسق-05:00

وقت يونكس لا يأخذ في الاعتبار الثواني الكبيسة. وبدلاً من ذلك، يفترض أن كل يوم تقويمي يحتوي بالضبط على 86,400 ثانية. نظرًا لأنه يتم تجاهل الثواني الكبيسة في العداد (مشاركة نفس قيمة الطابع الزمني تمامًا مثل الثانية السابقة)، فإن وقت Unix لا يحافظ على تزامن خطي مثالي مع التوقيت العالمي المنسق (UTC) عبر فترات جيولوجية طويلة. بالنسبة للتواريخ التي تسبق حد البداية في 1 يناير 1970، يستخدم النظام قيمًا صحيحة سالبة (على سبيل المثال، -86400 يشير إلى 31 ديسمبر 1969، 00:00:00 بالتوقيت العالمي المنسق).

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

  • ساعة واحدة: 3,600 ثانية
  • يوم واحد: 86,400 ثانية
  • أسبوع واحد: 604,800 ثانية
  • شهر واحد (يتم حسابه بـ 30.44 يومًا): 2,629,743 ثانية
  • سنة واحدة (محسوبة بـ 365.24 يومًا): 31,556,926 ثانية

يؤدي حساب قيم المدة مباشرةً باستخدام هذه القيم إلى تسهيل التعامل مع جداول cron، أو انتهاء صلاحية رموز JWT، أو إنشاء مؤشرات TTL مخصصة في قواعد بيانات NoSQL.

الثواني مقابل المللي ثانية: التنقل بدقة الأرقام

تعمل الطوابع الزمنية في البرامج الحديثة بمستويات مختلفة من الدقة اعتمادًا على متطلبات التطبيق. تستخدم معظم تصميمات النظام أحد هذه الحلول الأربعة:

  1. الثواني (تنسيق مكون من 10 أرقام): على سبيل المثال، 1735689600. هذا هو الحل القياسي الذي تستخدمه Python وPHP وقواعد البيانات العلائقية (مثل PostgreSQL وMySQL) وبيئات Linux Shell.
  2. ميلي ثانية (تنسيق مكون من 13 رقمًا): على سبيل المثال، 1735689600000. يعد هذا التنسيق قياسيًا في JavaScript وJava ومعظم واجهات برمجة تطبيقات الويب الحديثة المستندة إلى JSON.
  3. ميكروثانية (تنسيق مكون من 16 رقمًا): على سبيل المثال، 1735689600000000. مخصص عادةً للتتبع عالي الدقة وتسجيل النظام ومنصات التشخيص منخفضة المستوى.
  4. النانو ثانية (تنسيق مكون من 19 رقمًا): تُستخدم في أنظمة التتبع المتخصصة على مستوى kernel وشبكات المعالجة في الوقت الفعلي.

لتحويل الثواني إلى ميلي ثانية، اضرب قيمة العدد الصحيح في 1000. وعلى العكس من ذلك، لتحويل المللي ثانية مرة أخرى إلى الثواني القياسية، قم بتطبيق قسمة الأعداد الصحيحة على 1000 لإزالة الأرقام الزائدة.

يوفر فهم الطوابع الزمنية التاريخية والمتسلسلة لنظام Unix منظورًا واضحًا للتقدم الزمني والحجم:

الطابع الزمني ليونكس التاريخ والوقت المعادل لـ UTC سياق الحدث
0 الخميس 1 يناير 1970، 00:00:00 بالتوقيت العالمي عصر يونكس
1,000,000,000 الأحد 9 سبتمبر 2001، الساعة 01:46:40 بالتوقيت العالمي الإنجاز المليار ثانية
1,234,567,890 الجمعة 13 فبراير 2009، الساعة 23:31:30 بالتوقيت العالمي تقدم متسلسل للأرقام العشرية
1,735,689,600 الأربعاء 1 يناير 2025، 00:00:00 بالتوقيت العالمي بداية عام 2025
2,000,000,000 الثلاثاء 18 مايو 2033، الساعة 03:33:20 بالتوقيت العالمي ثاني مليارين من الإنجاز
2,147,483,647 الثلاثاء 19 يناير 2038، الساعة 03:14:07 بالتوقيت العالمي الحد الأقصى المطلق الموقع 32 بت

مشكلة عام 2038: لماذا تفشل أنظمة 32 بت

الأنظمة القديمة والبرامج الثابتة المضمنة ومخططات قواعد البيانات التي تخزن الطوابع الزمنية لنظام Unix على أنها أعداد صحيحة 32 بت ستواجه في النهاية حدًا لتجاوز السعة. يمكن لعدد صحيح 32 بت مُوقع تخزين قيم تصل إلى 2,147,483,647 فقط. تحدث نقطة الانهيار الدقيقة في 19 يناير 2038، الساعة 03:14:07 بالتوقيت العالمي.

عند العلامة التالية لساعة النظام (03:14:08 بالتوقيت العالمي المنسق)، يفيض عداد الأعداد الصحيحة ويلتف حول الحد الأدنى السلبي وهو -2,147,483,648. الأنظمة التي تفشل في التعامل مع هذا التحول ستفسر التاريخ على أنه 13 ديسمبر 1901. سيؤدي هذا إلى تعطل النظام وإبطال الشهادات وأخطاء نظام الملفات واستعلامات قاعدة البيانات التالفة.

طرق برمجية لتحويل وإنشاء الطوابع الزمنية لنظام Unix

لمساعدة المطورين على التقاط الوقت الحالي وإجراء التحويلات، يوضح الجدول أدناه طرق استرداد الطوابع الزمنية القياسية للحقبة وتحويل قيمة عامة (باستخدام 1800000000 كمرجع) مرة أخرى إلى التوقيت المحلي عبر اللغات والأنظمة الأساسية المختلفة.

اللغة / المنصة العصر الحالي (ثواني) تحويل العصر إلى التاريخ
جافا سكريبت Math.floor(Date.now() / 1000) تاريخ جديد (1800000000 * 1000).toLocaleString ()
بايثون كثافة العمليات (time.time ()) الوقت.ctime(1800000000)
جافا Instant.now().getEpochSecond() New SimpleDateFormat("MM/dd/yyyy HH:mm:ss").format(new Date(1800000000L * 1000))
يذهب الوقت.الآن().يونيكس() الوقت.يونيكس (1800000000، 0)
PHP وقت() التاريخ ('ص'، 1800000000)
روبي Time.now.to_i الوقت.في(1800000000)
ج # DateTimeOffset.Now.ToUnixTimeSeconds() DateTimeOffset.FromUnixTimeSeconds(1800000000).LocalDateTime
سي ++ Duration_cast(system_clock::now().time_since_epoch()).count()
الصدأ SystemTime::now().duration_since(UNIX_EPOCH).unwrap().as_secs()
بيرل وقت التوقيت المحلي العددي (1800000000)
PostgreSQL SELECT EXTRACT(EPOCH FROM now()); حدد TO_TIMESTAMP(1800000000);
ماي إس كيو إل SELECT UNIX_TIMESTAMP(NOW()); حدد FROM_UNIXTIME(1800000000);
خادم SQL حدد DATEDIFF(SECOND, '1970-01-01', GETUTCDATE()); حدد DATEADD(SECOND, 1800000000, '1970-01-01');
سكليتي SELECT unixepoch(); SELECT datetime(1800000000, 'unixepoch');
يونيكس / لينكس شل التاريخ +%s التاريخ -ud @1800000000
ماك التاريخ +%s التاريخ -j -r 1800000000
بوويرشيل [DateTimeOffset]::Now.ToUnixTimeSeconds() [DateTimeOffset]::FromUnixTimeSeconds(1800000000).LocalDateTime
اكسل / جداول البيانات =(A1 / 86400) + 25569

العصور المخصصة ومولدات الطوابع الزمنية لندفة الثلج Discord

تستخدم البنى المختلفة فترات مرجعية متخصصة ودقة متزايدة اعتمادًا على الأنظمة الأساسية للأجهزة أو قواعد البيانات أو مواصفات التطبيق. تتضمن بعض هذه التنسيقات ما يلي:

  • الطابع الزمني لـLDAP: يتم حسابه في كتل تبلغ مساحتها 100 نانو ثانية بدءًا من 1 يناير 1601.
  • .NET DateTime Ticks: يتم حسابها في كتل تبلغ 100 نانو ثانية بدءًا من السنة الميلادية الأولى.
  • الطابع الزمني لـ Chrome/WebKit: يتم العد بالميكروثانية بدءًا من 1 يناير 1601.
  • Mac HFS+: يتم العد بالثواني بدءًا من 1 يناير 1904.
  • الطابع الزمني لـ NTP: يتم العد بالثواني بدءًا من 1 يناير 1900.
  • وقت نظام تحديد المواقع العالمي (GPS): يتم حسابه بالثواني والأسابيع بدءًا من 6 يناير 1980.
  • الطابع الزمني لـSAS: يتم العد بالثواني أو الأيام بدءًا من 1 يناير 1960.
  • بيانات الكاكاو الأساسية: يتم العد بالثواني بدءًا من 1 يناير 2001.
  • Excel OADate: يتم العد بالأيام الكسرية بدءًا من 1 يناير 1900.
  • الطابع الزمني FAT: يتم العد بالثواني بدءًا من عام 1980 أو 2000.
  • اليوم اليولياني: يقيس التقدم الزمني في الأيام من النقاط المرجعية الفلكية القديمة.
  • معرف Snowflake: تنسيق فهرسة لا مركزي للطوابع الزمنية يستخدمه Discord وTwitter (X).

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

يقوم Discord بإنشاء أعداد صحيحة غير موقعة 64 بت فريدة ولا مركزية (معرفات ندفة الثلج) لتحديد الكائنات مثل الرسائل والقنوات والخوادم والمستخدمين. على عكس الأعداد الصحيحة المتزايدة القياسية أو UUIDs ذات الحمل العالي، تقوم ندفة الثلج Discord بتضمين وقت الإنشاء الدقيق داخل المعرف نفسه، مما يساعد في الأداء في الأنظمة الموزعة.

ينقسم هيكل معرف ندفة الثلج Discord إلى أربعة مكونات متميزة:

  • الطابع الزمني (42 بت): يمثل المللي ثانية المنقضية منذ حقبة Discord المخصصة (المضبوطة على 1 يناير 2015، الساعة 00:00:00 بالتوقيت العالمي المنسق، أي ما يعادل الطابع الزمني لنظام Unix 1420070400000).
  • معرف العامل (5 بت): يمثل فهرس عامل الخادم الداخلي.
  • معرف العملية (5 بت): يمثل فهرس العملية الداخلية.
  • الزيادة (12 بت): عداد تسلسلي يُعاد تعيينه إلى 0 كل مللي ثانية لكل عملية.

لعرض التواريخ القابلة للقراءة في رسائل Discord والتي يتم ضبطها تلقائيًا حسب المنطقة الزمنية المحلية للمستخدم المشاهد، يستخدم المطورون مولدات الطوابع الزمنية لـ Discord. يؤدي إدخال طابع زمني قياسي لنظام Unix في هذه المولدات إلى إنتاج سلسلة تخفيض السعر منسقة. يسرد الجدول أدناه تنسيقات التصميم المتاحة:

بناء جملة تخفيض السعر مثال على الإخراج (لـ Unix 1735689600) وصف أسلوب العرض
<t:1735689600:t> 00:00 وقت قصير
<t:1735689600:T> 00:00:00 منذ وقت طويل
<t:1735689600:d> 01/01/2025 تاريخ قصير
<t:1735689600:D> 1 يناير 2025 تاريخ طويل
<t:1735689600:f> 1 يناير 2025 00:00 التاريخ/الوقت القصير
<t:1735689600:F> الأربعاء 1 يناير 2025 00:00 التاريخ/الوقت الطويل
<t:1735689600:R> في 5 سنوات / 5 سنوات مضت الوقت النسبي

تحسين سير العمل الزمني في الأنظمة الموزعة

تتطلب إدارة حسابات الوقت داخل الأنظمة الحديثة الموزعة اتباع نهج موحد لمنع انحرافات المنطقة الزمنية، وأخطاء تحديد حجم الحمولة، وتعطل التدفق الزائد. يؤدي توحيد هياكل قواعد البيانات في عصر Unix القياسي إلى تبسيط مهام معالجة الوقت، مما يضمن عمليات متسقة عبر الخدمات الصغيرة والواجهات الخارجية.

عند تصميم واجهات برمجة التطبيقات أو تكوين قوائم انتظار الرسائل، ضع هذه الإرشادات الثلاثة في الاعتبار:

  1. تخزين الوقت بتنسيق UTC أو عدد صحيح للعصر: حافظ على نظافة طبقات الثبات من إزاحات المنطقة الزمنية المحلية. قم بتطبيق التعريب حصريًا على طبقة العرض التقديمي.
  2. إعطاء الأولوية لتمثيل 64 بت: عند تصميم أعمدة قاعدة البيانات أو تحديد بنيات البرمجة، ابتعد عن أنواع 32 بت لمنع تجاوزات وقت التشغيل لعام 2038.
  3. اختر الدقة المناسبة: مطابقة مواصفات النظام (على سبيل المثال، استخدام المللي ثانية لأحداث واجهة برمجة التطبيقات (API) والنانو ثانية فقط عند تتبع عمليات اكتساب القفل الموزع).

عند تحويل الطوابع الزمنية أو التحقق من العصور باستخدام أدوات المتصفح المساعدة، يكون الأمان والخصوصية أمرًا بالغ الأهمية. تطبق أداة التحويل الخاصة بـ Toolsaur هذه الفلسفة مباشرةً: "يتم تشغيل كافة عمليات المعالجة محليًا في متصفحك. ولا يتم إرسال بياناتك إلى خوادمنا أبدًا." ويضمن هذا عدم تسرب سجلات النظام الحساسة التي تحتوي على الطوابع الزمنية لقاعدة البيانات إلى نقاط النهاية التابعة لجهات خارجية.

الأسئلة المتداولة حول محولات العصر

لماذا تعتبر الطوابع الزمنية لنظام Unix مستقلة عن المنطقة الزمنية؟

تمثل الطوابع الزمنية لنظام Unix الوقت المطلق المنقضي منذ نقطة مرجعية عالمية واحدة (1 يناير 1970، الساعة 00:00:00 بالتوقيت العالمي). نظرًا لأن نقطة البداية المرجعية هذه متطابقة بغض النظر عن الموقع الجغرافي، فإن العدد الصحيح للطابع الزمني المحسوب يظل كما هو. يتم تطبيق تعديل المنطقة الزمنية المحلية فقط عند تنسيق الطابع الزمني في سلسلة تاريخ يمكن قراءتها بواسطة الإنسان داخل واجهات العميل.

ما الفرق بين الطابع الزمني المكون من 10 أرقام والطابع الزمني المكون من 13 رقمًا؟

يمثل الطابع الزمني المكون من 10 أرقام الدقة بالثواني (على سبيل المثال، 1735689600)، وهو أمر نموذجي لأنظمة التشغيل POSIX وقواعد بيانات Python وSQL. يمثل الطابع الزمني المكون من 13 رقمًا الدقة بالمللي ثانية (على سبيل المثال، 1735689600000)، وهو معيار قياسي لأوقات تشغيل JavaScript وJava وواجهات برمجة تطبيقات REST الحديثة. ويتطلب التنقل بينهما الضرب أو القسمة على 1000.

كيف ستؤثر مشكلة عام 2038 على قواعد البيانات الحديثة؟

إذا قام عمود قاعدة البيانات بتخزين الطوابع الزمنية لنظام Unix باستخدام نوع بيانات عدد صحيح 32 بت (مثل INT في مخططات قاعدة البيانات الأقدم)، فإن أي سجل بطابع زمني بعد 19 يناير 2038، 03:14:07 بالتوقيت العالمي المنسق سوف يتسبب في تجاوز السعة. يؤدي هذا إلى التفاف الرقم إلى قيمة سالبة، وتفسير التواريخ المستقبلية على أنها 13 ديسمبر 1901. يجب أن تقوم الأنظمة بترحيل هذه الأعمدة إلى أعداد صحيحة 64 بت موقعة (BIGINT).

كيف يتعامل وقت يونكس مع الثواني الكبيسة؟

وقت يونكس لا يأخذ في الاعتبار الثواني الكبيسة ويفترض أن كل يوم يحتوي على 86400 ثانية بالضبط. عند حدوث ثانية كبيسة، يتم تكرار الطابع الزمني لنظام Unix أو إيقافه لمدة ثانية. يعمل اختيار التصميم هذا على تبسيط العمليات الحسابية الحسابية ولكنه يتسبب في انحرافات طفيفة عن الجداول الزمنية الدقيقة للتوقيت العالمي المنسق (UTC).

ما هو معرف Discord snowflake وكيف يختلف عن الطابع الزمني القياسي لنظام Unix؟

معرف Discord snowflake هو عدد صحيح مخصص غير موقّع 64 بت يقوم بتشفير الطابع الزمني للإنشاء بالإضافة إلى البيانات التعريفية لهندسة الخادم (معرف العامل، ومعرف العملية، والزيادة المحلية). على عكس الطابع الزمني القياسي لنظام Unix المكون من 10 أرقام بالثواني، يستخدم معرف ندفة الثلج حقبة مخصصة تبدأ من 1 يناير 2015، ويتتبع الفواصل الزمنية بالمللي ثانية، ويخزن هذا الوقت عالي الدقة في أول 42 بت من المعرف.

كيف يمكنك تحويل الطابع الزمني للعصر في Microsoft Excel؟

يتتبع Excel التواريخ بعدد الأيام المنقضية منذ 1 يناير 1900. لتحويل طابع زمني Unix قياسي مكون من 10 أرقام (ثواني) في الخلية A1 إلى تاريخ قابل للقراءة في Excel، قم بتطبيق الصيغة =(A1 / 86400) + 25569، حيث 86400 هو عدد الثواني في اليوم و25569 هو الإزاحة في الأيام بين عصر Excel وعصر Unix. اضبط تنسيق الخلية على "التاريخ" أو "الوقت" لعرض الإخراج.