DateTime64

يتيح تخزين نقطة زمنية يمكن التعبير عنها كتاريخ تقويمي ووقت من اليوم، مع دقة محددة لأجزاء من الثانية حجم الـtick (precision): ‏10^-precision ثانية. النطاق الصالح: [ 0 : 9 ]. وعادةً ما تُستخدم القيم: 3 (ميلي ثانية)، 6 (ميكروثانية)، 9 (نانوثانية). القيمة الافتراضية: 3 (ميلي ثانية). الصياغة:

DateTime64(precision, [timezone])

داخليًا، يخزّن البيانات على شكل عدد من ‘ticks’ منذ بداية epoch ‏(1970-01-01 00:00:00 UTC) بصيغة Int64. ويتحدد مستوى دقة الـ tick بواسطة المعلَمة precision. بالإضافة إلى ذلك، يمكن للنوع DateTime64 تخزين منطقة زمنية واحدة للعمود بأكمله، ما يؤثر في كيفية عرض قيم النوع DateTime64 بتنسيق نصي وكيفية تفسير القيم المحددة كسلاسل نصية (‘2020-01-01 05:00:01.000’). لا تُخزَّن المنطقة الزمنية في صفوف الجدول (أو في مجموعة النتائج)، بل تُخزَّن في البيانات الوصفية للعمود. راجع التفاصيل في DateTime. النطاق المدعوم للقيم: [0000-01-01 00:00:00, 9999-12-31 23:59:59.999999999] يعتمد عدد الخانات بعد الفاصلة العشرية على المعلَمة precision. ملاحظة: النطاق الكامل أعلاه متاح لدقة تصل إلى 7. وبما أن ticks تُخزَّن في Int64، فإن الدقات الأعلى تغطي نطاقًا أضيق: عند الدقة 8 تكون القيمة القصوى تقريبًا 4892-10-07، وعند استخدام الدقة القصوى البالغة 9 خانات (نانوثانية) يكون النطاق المدعوم من 1677-09-21 00:12:44 إلى 2262-04-11 23:47:16 بتوقيت UTC.

أمثلة

إنشاء جدول يحتوي على عمود من النوع DateTime64 وإدراج البيانات فيه:

CREATE TABLE dt64
(
    `timestamp` DateTime64(3, 'Asia/Istanbul'),
    `event_id` UInt8
)
ENGINE = MergeTree;

-- Parse DateTime64
-- - from an integer interpreted as the number of seconds since 1970-01-01 (like DateTime),
-- - from a decimal interpreted as the number of seconds, the fractional part giving sub-second precision,
-- - from a string.

INSERT INTO dt64
VALUES
(1546300800, 1),
(1546300800.123, 2),
('2019-01-01 00:00:00', 3);

SELECT * FROM dt64;

┌───────────────timestamp─┬─event_id─┐
│ 2019-01-01 03:00:00.000 │        1 │
│ 2019-01-01 03:00:00.123 │        2 │
│ 2019-01-01 00:00:00.000 │        3 │
└─────────────────────────┴──────────┘

عند إدراج datetime كعدد، يُتعامل معه على أنه Unix timestamp ‏(UTC) بالثواني، كما في DateTime. تمثل 1546300800 القيمة '2019-01-01 00:00:00' بتوقيت UTC. ومع ذلك، بما أن العمود timestamp محددة له المنطقة الزمنية Asia/Istanbul ‏(UTC+3)، فعند إخراجه كسلسلة نصية ستظهر القيمة بالشكل '2019-01-01 03:00:00'. يعمل إدراج عدد ذي جزء كسري بالطريقة نفسها: الجزء قبل الفاصلة العشرية هو Unix timestamp بالثواني، ويوفر الجزء بعدها دقة أجزاء من الثانية وفقًا لدقة العمود. (قبل الإصدار 26.8، كان العدد الصحيح المجرّد غير الموضوع بين علامتَي اقتباس في مسارات الإدخال JSON وValues/Quoted — ويشمل الأخير كل تنسيق يحلل الحقول باستخدام قاعدة الإفلات Quoted: وهي Values وMySQLDump وTemplate/CustomSeparated/Regexp المهيأة بإفلات الحقول Quoted — يُفسَّر بدلًا من ذلك على أنه القيمة الخام الأساسية بدقة العمود، لذا كانت 1546300800000 عند الدقة 3 تعني '2019-01-01 00:00:00'. لاستعادة السلوك السابق في هذه المسارات، اضبط input_format_read_datetime_number_as_raw_value = 1 (أو SET compatibility = '26.7')؛ يؤثر ذلك أيضًا في الدالة JSONExtract ونوع البيانات JSON. ينطبق إعداد التوافق على عدد صحيح مجرّد فقط: ففي تنسيق Values، يعود العدد الكسري، الذي يرفضه محلل البث القديم، إلى تقييم تعبير SQL ويُقرأ بالثواني — كما هو الحال في الإصدارات السابقة للإصدار 26.8. في JSONExtract ونوع البيانات JSON، تُحلل القيمة الكسرية عبر Float64، لذا قد يُقرَّب الطابع الزمني الذي يحتوي على أرقام أكثر مما يمكن لـ Float64 الاحتفاظ به إلى القيمة المجاورة، بخلاف تنسيقات إدخال الصفوف التي تحلل النص الأصلي بدقة. لا يحكم هذا الإعداد تنسيقات إدخال النص المفصول بعلامات الجدولة وCSV وغيرها من تنسيقات النص ذات الإفلات، وتحتفظ بتفسيرها الحالي للعدد غير الموضوع بين علامتَي اقتباس: تُقرأ القيمة الكبيرة على أنها tick.)
عند إدراج قيمة نصية كسمة datetime، يُتعامل معها على أنها ضمن المنطقة الزمنية الخاصة بالعمود. ستُعامل '2019-01-01 00:00:00' على أنها ضمن المنطقة الزمنية Asia/Istanbul، وتُخزَّن على أنها 1546290000000.

التصفية على قيم DateTime64

SELECT * FROM dt64 WHERE timestamp = toDateTime64('2019-01-01 00:00:00', 3, 'Asia/Istanbul');

┌───────────────timestamp─┬─event_id─┐
│ 2019-01-01 00:00:00.000 │        3 │
└─────────────────────────┴──────────┘

بخلاف DateTime، لا تُحوَّل قيم DateTime64 تلقائيًا من String.

SELECT * FROM dt64 WHERE timestamp = toDateTime64(1546300800.123, 3);

┌───────────────timestamp─┬─event_id─┐
│ 2019-01-01 03:00:00.123 │        1 │
│ 2019-01-01 03:00:00.123 │        2 │
└─────────────────────────┴──────────┘

كما هو الحال عند إدراج رقم، تتعامل الدالة toDateTime64 مع الوسيط الرقمي باعتباره عددًا من الثواني، لذا يجب تحديد دقة أجزاء من الثانية بعد العلامة العشرية.

الحصول على المنطقة الزمنية لقيمة من نوع DateTime64:

SELECT toDateTime64(now(), 3, 'Asia/Istanbul') AS column, toTypeName(column) AS x;

┌──────────────────column─┬─x──────────────────────────────┐
│ 2023-06-05 00:09:52.000 │ DateTime64(3, 'Asia/Istanbul') │
└─────────────────────────┴────────────────────────────────┘

تحويل المنطقة الزمنية

SELECT
toDateTime64(timestamp, 3, 'Europe/London') AS lon_time,
toDateTime64(timestamp, 3, 'Asia/Istanbul') AS istanbul_time
FROM dt64;

┌────────────────lon_time─┬───────────istanbul_time─┐
│ 2019-01-01 00:00:00.123 │ 2019-01-01 03:00:00.123 │
│ 2019-01-01 00:00:00.123 │ 2019-01-01 03:00:00.123 │
│ 2018-12-31 21:00:00.000 │ 2019-01-01 00:00:00.000 │
└─────────────────────────┴─────────────────────────┘

راجع أيضًا

مرجع SQL

أنواع البيانات

المحركات

الدوال

التنسيقات

الواجهات

الإعدادات

جداول النظام

بحيرات البيانات

أمثلة

​أمثلة

أمثلة