محول الطوابع الزمنية: دليل شامل
طوابع Unix الزمنية هي الطريقة الأكثر شيوعاً لتمثيل الوقت في أنظمة الكمبيوتر. كرقم واحد يمثل الثواني منذ 1 يناير 1970، تبسط طوابع Unix الزمنية حسابات الوقت، والمقارنات، والتخزين. يشرح هذا الدليل الشامل ما هي طوابع Unix الزمنية، وكيفية استخدامها، والمزالق الشائعة التي يجب تجنبها.
ما هو طابع Unix الزمني؟
طابع Unix الزمني (يسمى أيضاً Unix time أو POSIX time أو Epoch time) هو رقم واحد يمثل عدد الثواني التي مرت منذ Unix Epoch: منتصف الليل UTC في 1 يناير 1970. على سبيل المثال، طابع زمني 1609459200 يمثل 1 يناير 2021 الساعة 00:00:00 UTC. هذا التمثيل البسيط لديه فوائد قوية. أولاً، إنه محايد للمنطقة الزمنية. الطابع الزمني يمثل لحظة مطلقة في الوقت - نفس الثانية في كل مكان على الأرض. المناطق الزمنية تأتي فقط عند تحويل إلى قراءة بشرية. هذا يتجنب مشاكل المنطقة الزمنية المعقدة في حسابات الوقت. ثانياً، الطوابع الزمنية تجعل حسابات الوقت تافهة. الفرق بين طابعين زمنيين هو ببساطة الطرح. إيجاد الوقت الأقدم هو مجرد مقارنة. إضافة ساعة تعني إضافة 3600 (ثواني في ساعة). لا حاجة للقلق بشأن الأشهر ذات الأطوال المختلفة، أو سنوات كبيسة، أو تعديلات التوقيت الصيفي. ثالثاً، التخزين فعال. طابع زمني عادة عدد صحيح 32 بت أو 64 بت - 4 أو 8 بايتات. مقارنة بتخزين السنة والشهر واليوم والساعة والدقيقة والثانية والمنطقة الزمنية بشكل منفصل، توفر الطوابع الزمنية مساحة كبيرة. رابعاً، الطوابع الزمنية قابلة للفرز بشكل طبيعي. طابع زمني أكبر يعني وقتاً لاحقاً. يمكنك فرز السجلات بالطابع الزمني، وإيجاد الأحداث الأخيرة، أو تجميع حسب فترات زمنية كلها باستخدام عمليات الأعداد الصحيحة البسيطة. ومع ذلك، الطوابع الزمنية لها قيود. طوابع Unix الزمنية الأكثر شيوعاً 32 بت تعاني من "مشكلة عام 2038" - في 19 يناير 2038، سينفد عدد صحيح موقع 32 بت، ويلتف إلى أرقام سالبة. يتطلب هذا الترقية إلى طوابع زمنية 64 بت، التي يمكن أن تمثل تواريخ لمليارات السنين في المستقبل. دقة الطابع الزمني مهمة. طوابع Unix الزمنية الكلاسيكية تحسب الثواني. للتطبيقات عالية الدقة، تستخدم الأنظمة طوابع زمنية بالمللي ثانية (ms منذ Epoch) أو حتى طوابع زمنية بالميكروثانية أو النانوثانية. JavaScript، على سبيل المثال، يستخدم طوابع زمنية بالمللي ثانية بشكل افتراضي.
التحويل بين الطوابع الزمنية والتواريخ
التحويل بين طوابع Unix الزمنية وتواريخ قابلة للقراءة من قبل البشر هو عملية شائعة ولكنها تتطلب اعتناءً بالمناطق الزمنية. لتحويل طابع زمني إلى تاريخ، تحتاج إلى مكتبة تاريخ/وقت. في JavaScript: new Date(timestamp * 1000) (اضرب في 1000 لأن JavaScript يستخدم المللي ثانية). في Python: datetime.fromtimestamp(timestamp). في PHP: date('Y-m-d H:i:s', timestamp). كل لغة لديها أدوات مدمجة. تحذير مهم: هذه التحويلات تستخدم المنطقة الزمنية المحلية للنظام بشكل افتراضي. طابع زمني 1609459200 يصبح "2021-01-01 00:00:00" في UTC، لكن "2020-12-31 16:00:00" في نيويورك (UTC-8 خلال الشتاء). كن دائماً واضحاً حول المنطقة الزمنية المقصودة. للعمل مع UTC صراحةً (موصى به): JavaScript يستخدم toUTCString() أو getUTCFullYear() وطرق مشابهة. Python يستخدم datetime.utcfromtimestamp(). PHP يستخدم gmdate() بدلاً من date(). عند التعامل مع الطوابع الزمنية، فكر في UTC كخيار افتراضي. لتحويل تاريخ إلى طابع زمني، استخدم وظيفة التحليل المناسبة. JavaScript: Math.floor(Date.parse(dateString) / 1000). Python: int(datetime.timestamp()). PHP: strtotime(). مرة أخرى، انتبه إلى المناطق الزمنية. عند عرض الطوابع الزمنية للمستخدمين، حولها إلى منطقتهم الزمنية المحلية. يريد المستخدمون رؤية الوقت بتوقيتهم المحلي، وليس UTC. استخدم مكتبات مثل moment.js أو date-fns (JavaScript)، أو pytz (Python)، أو Carbon (PHP) لمعالجة المنطقة الزمنية الصحيحة. لواجهات برمجة التطبيقات، استخدم دائماً طوابع زمنية أو سلاسل ISO 8601 مع معلومات المنطقة الزمنية. تجنب إرسال تواريخ غامضة مثل "2021-01-01 10:00:00" دون مؤشر منطقة زمنية - هل هذا UTC؟ توقيت نيويورك؟ توقيت المستخدم المحلي؟ الغموض يؤدي إلى أخطاء. تنسيقات التاريخ القياسية مثل ISO 8601 (2021-01-01T10:00:00Z) واضحة وقابلة للآلة. "Z" تعني UTC، أو يمكنك تحديد التعويض: "2021-01-01T10:00:00-05:00" لـ UTC-5. استخدم هذه التنسيقات عند الإمكان للوضوح.
المشاكل الشائعة ومحاذير المنطقة الزمنية
معالجة الوقت معقدة، وحتى المطورين ذوي الخبرة يرتكبون أخطاء. يساعدك فهم المزالق الشائعة على تجنب الأخطاء الدقيقة. خلط الثواني والمللي ثانية هو الخطأ رقم واحد. طوابع Unix الزمنية عادةً بالثواني، ولكن JavaScript يستخدم المللي ثانية. إذا كان طابع زمني يبدو طويلاً بشكل غريب (13 رقماً بدلاً من 10)، فمن المحتمل أن يكون بالمللي ثانية. تحويل: تقسيم على 1000 للذهاب من المللي ثانية إلى الثواني، واضرب في 1000 للعكس. افتراض UTC عندما تعني المحلي (أو العكس) يخلق أخطاء دقيقة. عند التحليل "2021-01-01"، تفترض بعض الأنظمة UTC، والبعض الآخر يفترض المنطقة الزمنية المحلية. كن صريحاً. إذا كنت تعني UTC، قل ذلك. إذا كنت تعني محلياً، قل ذلك. تجاهل التوقيت الصيفي (DST) يسبب مشاكل مرتين في السنة. عند إضافة "يوم واحد" إلى تاريخ، يمكن أن تحصل على 23 أو 25 ساعة بسبب تحولات DST. استخدم مكتبات واعية بالمنطقة الزمنية تتعامل مع DST بشكل صحيح. لا تحاول القيام بحساب التاريخ/الوقت بنفسك. ثواني القفز هي حافة حالة. يتم إضافة ثانية قفز عرضياً لإبقاء الوقت متزامناً مع دوران الأرض. معظم الأنظمة تتجاهلها، ولكن في التطبيقات عالية الدقة، قد تهم. كن على علم بأن الأوقات الدقيقة جداً قد تحتاج إلى اعتبارات خاصة. فرز التواريخ المخزنة كسلاسل يفشل. "2021-01-09" يأتي بعد "2021-01-10" عند الفرز الأبجدي. استخدم دائماً طوابع زمنية للتخزين والفرز. حولها إلى سلاسل قابلة للقراءة فقط للعرض. مشكلة عام 2038 قادمة. طوابع زمنية 32 بت تنفد في 19 يناير 2038. الأنظمة الحديثة تستخدم طوابع زمنية 64 بت، التي تحل هذا. ولكن الأنظمة القديمة والأجهزة المضمنة قد لا تزال عالقة في 32 بت. خطط للترقية قبل عام 2038. المناطق الزمنية تتغير. الحكومات تغير قواعد DST، وتضيف مناطق زمنية جديدة، وتحول التعويضات. حافظ على بيانات المنطقة الزمنية الخاصة بك محدثة. استخدم قاعدة بيانات IANA للمنطقة الزمنية (tzdata)، التي يتم تحديثها بانتظام. عدم التحقق من صحة مدخلات المستخدم للتواريخ يؤدي إلى أخطاء. "30 فبراير" غير صالح. "25:00:00" غير صالح. تحقق دائماً من صحة مدخلات التاريخ/الوقت قبل المعالجة. استخدم مكتبات التحليل المناسبة التي ترفض التواريخ غير الصالحة. تخزين التواريخ في مناطق زمنية محلية في قاعدة البيانات هو خطأ شائع. خزن دائماً في UTC. حول إلى محلي فقط للعرض. هذا يتجنب الالتباس ويجعل الاستعلامات أبسط. عمود "created_at" يجب أن يكون دائماً UTC.
جرب الأداة
محول الطابع الزمني
اعرف المزيد
الأسئلة الشائعة
محول الطابع الزمني
الأسئلة الشائعة →