ما هو توقيت يونكس؟

تُعدّ مُدة Unix هي عدد الثواني (أو المليونات) التي تمرّ منذ 1 يناير 1970، 00:00:00 بتوقيت UTC. وهي طريقة عالمية ومستقلة عن المناطق الزمنية لتمثيل لحظة معينة في الزمن.

كيف أحوّل وقت Unix إلى تاريخ قابل للقراءة في JavaScript؟

اضرب الوقت المُحدد بـ 1000 (لتحويل الثواني إلى المليونات)، ثم امرِّرها إلى مُصنّف التاريخ: new Date(timestamp * 1000). استخدم .toISOString() أو .toLocaleString() لتنسيقها.

لماذا تظهر مُلَفَّتِي Unix كـ 1970؟

هذا يُعني عادةً أنك تمر بفترة زمنية مُقدَّمة بالمليونات من الثانية، بينما يُتوقع أن تكون بالثواني، أو العكس. تحقق من أن رقم توقيت الـ 10 أرقام (ثواني) أو 13 رقمًا (مليونات من الثانية)، وقم بتحويله وفقًا لذلك.

هل تتأثر الأوقات المُقَيَّمة بالساعات المُتَحَوِّلة؟

لا. يمثل توقيت Unix دائمًا لحظة في الوقت العالمي (UTC). تؤثر مناطق الوقت فقط على طريقة عرض أو تفسير هذا التوقيت في طبقة تطبيقك.

ما هو مشكلة 2038؟

الأنظمة التي تُخزن فيها تواريخ Unix كأعداد صحيحة ذات 32 بت ستُتجاوز في 19 يناير 2-2038. تستخدم الأنظمة الحديثة أعداد صحيحة ذات 64 بت، وهي آمنة لبلايين السنين. الأنظمة المُدمجة القديمة والخطط القديمة للقواعد البيانات التي تستخدم نوع INT(11) لتواريخ التوقيت هي المخاطر الرئيسية.

لا تحب الإعلانات؟ يذهب خالية من الإعلانات اليوم 

طوابع زمن يونكس كيفية التحويل وسبب انتشارها في كل الأماكن

نُشرت في 18 أبريل 2026

مصدر عملي للاستخدام مع أوقات Unix: الثواني مقابل المليونات، التحويل في JavaScript وPython وSQL وBash، مصادر الأخطاء المتعلقة بالساعات، ومتى يُستخدم الأوقات بدلاً من سلاسل ISO 8601.

التوقيتات المُستَخدمة في نظام يونكس: كيفية التحويل والسبب في وقوعها في كل الأماكن 1

إعلان · حذف؟

أوقات Unix: كيفية التحويل وسبب واسع استخدامها

يُعرف التوقيت المُستَخدم في نظام يونكس (Unix timestamp) بأنه عدد الثواني التي تمر منذ 1 يناير 1970، 00:00:00 بتوقيت UTC — ويُعرف أيضًا باسم "العصر اليونكس". لم يُختار هذا التاريخ لأي سبب تقني، بل كان هو السنة الحالية عندما تم تصميم يونكس. يُعتبر العصر دائمًا بتوقيت UTC، مما يعني أن التوقيت مثل 1712800000 يُمثل نفس اللحظة في كل مكان على الأرض، بغض النظر عن المنطقة الزمنية.

يُستخدم التوقيت المُستَخدم في نظام يونكس في كل الأماكن: في عناوين HTTP، في توقيتات JWT، في سجلات قواعد البيانات، في ملفات السجلات، في صفوف الرسائل، وفي إجابات واجهات برمجة التطبيقات. إذا كنت تُطور أو تُحلل أي شيء يحتوي على وقت، فستُواجه هذا النوع من التوقيتات باستمرار. التوقيت المُستَخدم في نظام يونكس مُحول التوقيت المُستَخدم في نظام يونكس على IO Tools مفيد للاستعلام السريع، ولكنك أيضًا تحتاج إلى معرفة كيفية التعامل معه في الكود.

الثواني مقابل المليونات: الخطأ الشائع الذي يصيب الجميع

أكبر خطأ في التوقيتات في البيئات الإنتاجية: الخلط بين الثواني والميليونات. يستخدم المعيار اليونكس الثواني. يُرجع لغة جافاسكربت Date.now() إلى المليونات. كذلك يُرجع لغة جافا System.currentTimeMillis().

إذا كان التوقيت 1712800000 فهو أبريل 2024. أما إذا كان التوقيت 1712800000000 (مليونات) فهو يُشير إلى سنة 56 ألفًا ما يزيد. إذا كان حسابك للتواريخ يُنتج تواريخ في المستقبل بعقود أو يُعرض 1970-01-01فهذا هو السبب الرئيسي.

مبدأ عام: إذا كان التوقيت يحتوي على 13 رقمًا، فهو مُقاس بالميليونات، وإذا كان يحتوي على 10 أرقام، فهو مُقاس بالثواني. في حالة الشك، قسّم على 1000 وتحقق مما إذا كان الناتج منطقيًا.

تحويل التوقيت المُستَخدم في نظام يونكس حسب اللغة

إليك الأنماط التي ستستخدمها في الواقع:

جافا سكريبت

// Get current timestamp (milliseconds — divide by 1000 for seconds)
const tsMs = Date.now();           // e.g. 1712800000000
const tsSec = Math.floor(Date.now() / 1000); // e.g. 1712800000

// Convert seconds timestamp to Date object
const ts = 1712800000;
const date = new Date(ts * 1000);  // must multiply by 1000
console.log(date.toISOString());   // "2024-04-11T02:13:20.000Z"

// Convert Date back to Unix timestamp (seconds)
const tsBack = Math.floor(date.getTime() / 1000);

بايثون

from datetime import datetime, timezone

# Get current timestamp (seconds)
import time
ts = int(time.time())  # e.g. 1712800000

# Convert timestamp to datetime (UTC-aware)
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
print(dt.isoformat())  # 2024-04-11T02:13:20+00:00

# Convert local-naive datetime to timestamp (risky — see timezone section)
ts_back = int(dt.timestamp())

قاعدة قواعد بيانات (MySQL / MariaDB)

-- Convert timestamp to datetime
SELECT FROM_UNIXTIME(1712800000);
-- Result: 2024-04-11 02:13:20 (server timezone applies here)

-- Get current Unix timestamp
SELECT UNIX_TIMESTAMP();

-- Convert datetime string to timestamp
SELECT UNIX_TIMESTAMP('2024-04-11 02:13:20');

Bash

# Get current timestamp
date +%s

# Convert timestamp to human-readable (GNU date)
date -d @1712800000
# Output: Thu Apr 11 02:13:20 UTC 2024

# macOS (BSD date)
date -r 1712800000

جدول مرجعي سريع

لغة	الحصول عن الوقت الحالي (بالثواني)	التوقيت إلى تاريخ	التاريخ إلى توقيت
جافا سكريبت	`Math.floor(Date.now()/1000)`	`new Date(ts * 1000)`	`Math.floor(d.getTime()/1000)`
بايثون	`int(time.time())`	`datetime.fromtimestamp(ts, tz=timezone.utc)`	`int(dt.timestamp())`
MySQL	`UNIX_TIMESTAMP()`	`FROM_UNIXTIME(ts)`	`UNIX_TIMESTAMP(datetime_str)`
Bash	`date +%s`	`date -d @ts`	`date -d "2024-04-11" +%s`

مفارقات التوقيت

يُعتبر التوقيت المُستَخدم في نظام يونكس دائمًا بتوقيت UTC. دائمًا. الرقم 1712800000 لا يحتوي على منطقة زمنية — بل يُعدّ عدد الثواني من العصر. التوقيت المُستخدم للعرض هو مسألة عرض، وليس مسألة تخزين.

أين يُصيب المطورون:

في بيئة بيئة بيثون datetime.fromtimestamp(ts) بدون tz=timezone.utc — يستخدم المنطقة الزمنية المحلية للخادم، بشكل سري. استخدم fromtimestamp(ts, tz=timezone.utc) بدلاً من.
في قاعدة بيانات ماريا دب FROM_UNIXTIME() — يُحول إلى إعداد المنطقة الزمنية للخادم (@@session.time_zone). إذا كان الخادم في منطقة زمنية UTC+8، فإن النتيجة تتحرك بـ 8 ساعات.
التخزين datetime في قاعدة بيانات ماريا دب بدون توحيد بتوقيت UTC — إذا كانت خادم تطبيقك وقاعدة البيانات في مناطق زمنية مختلفة، فإن كل إدخال أو قراءة تُعدّ خطأ مُنتظرًا.

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

التوقيتات مقابل سلسلة ISO 8601: ما الذي يجب تخزينه؟

كلاهما صيغة صالحة لتخزين البيانات. المزايا والعيوب:

التوقيت المُستَخدم في نظام يونكس (عدد صحيح): مضغوط، سريع في المقارنات والحسابات، لا يحتوي على تناقضات للمنطقة الزمنية، ويعمل على كل أنواع قواعد البيانات. العيب: ليس قابلًا للقراءة من قبل الإنسان دون أداة.
سلسلة ISO 8601 (مثلاً) 2024-04-11T02:13:20Z: قابل للقراءة من قبل الإنسان داخل قاعدة البيانات، وذات توثيق ذاتي. العيب: أبطأ في استعلامات المدى، ويمكن أن يُغفل أو يُستخدم خطأ للمنطقة الزمنية.

لأغلب التطبيقات: تخزين التوقيتات كأعداد صحيحة. استخدم سلسلة ISO 8601 في واجهات برمجة التطبيقات والسجلات حيث يُهم القدرة على القراءة من قبل الإنسان. إذا كنت مُلزمًا بتخزين سلسلة ISO 8601، فاستخدم دائمًا Z أو التوقيت المُحدد — التوقيت بدون منطقة زمنية هو كارثة في أنظمة التوزيع. 2024-04-11 02:13:20 بلا توقيت مناطق هو كارثة في أنظمة التوزيع.

مشكلة 2038

يمكن لعدد صحيح مُستَخدم في 32 بت أن يحتوي على قيمة أقصى تساوي 2147483647، والذي يُقابل 1 يناير 2038، 03:14:07 بتوقيت UTC. الأنظمة التي تُخزن التوقيت المُستَخدم في نظام يونكس كعدد صحيح مُستَخدم في 32 بت ستصبح مُفرطة عند هذا الوقت — وتُعيد التوقيت إلى 1901 أو تنهار. int سيتجاوز في تلك اللحظة — عودة إلى 1901 أو توقف النظام.

هل يجب أن تقلق؟ إذا كنت تكتب كودًا جديدًا، لا — استخدم الأعداد الصحيحة ذات 64 بت. إذا كنت تُحافظ على كود قديم مكتوب بلغة C، أو برمجيات مُدمجة قديمة، أو مخططات قواعد بيانات قديمة تستخدم INT(11) لتخزين التوقيتات، فهذا يستحق التحقق من ذلك. نوع قاعدة بيانات ماريا دب TIMESTAMP متأثر أيضًا؛ DATETIME لا يتأثر. الأنظمة الحديثة التي تستخدم التوقيتات ذات 64 بت آمنة حتى عام 292 مليار.

هل تحتاج إلى تحويل التوقيتات بسرعة دون كتابة كود؟ فإن مُحول التوقيت المُستَخدم في نظام يونكس على IO Tools يُعالج الثواني والميليونات، ويعرض الوقت بتوقيت UTC والتوقيت المحلي معًا، ويسمح لك بنسخ تاريخ لاسترجاع التوقيت.