هل يجب استخدام نوع بيانات التاريخ أو الطابع الزمني في MySQL؟

في MySQL 5 وما فوق ، يتم تحويلالطابع الزمنيالقيم من المنطقة الزمنية الحالية إلى UTC للتخزين ، ويتم تحويلها مرة أخرى من UTC إلى المنطقة الزمنية الحالية للاسترجاع. (يحدث هذا فقط لنوع بيانات TIMESTAMP و لا لأنواع أخرى مثل DATETIME.)

بشكل افتراضي ، تكون المنطقة الزمنية الحالية لكل اتصال هي وقت الخادم. يمكن تعيين المنطقة الزمنية على أساس كل اتصال ، كما هو موضح في MySQL Server Time Zone Support.

أستخدم دائمًا حقول DATETIME لأي شيء آخر غير بيانات تعريف الصف (تاريخ الإنشاء أو التعديل).

كما المذكورة في وثائق MySQL:

يتم استخدام نوع DATETIME عندما تحتاج إلى قيم تحتوي على معلومات التاريخ والوقت. يقوم MySQL باسترداد قيم DATETIME وعرضها بتنسيق YYYY-MM-DD HH: MM: SS. النطاق المدعوم هو "1000-01-01 00:00:00" إلى "9999-12-31 23:59:59".

...

يحتوي نوع بيانات TIMESTAMP على نطاق من "1970-01-01 00:00:01" UTC إلى "2038-01-09 03:14:07" UTC. له خصائص مختلفة ، اعتمادًا على إصدار MySQL ووضع SQL الذي يعمل عليه الخادم.

من المحتمل جدًا أن تصل إلى الحد الأدنى على TIMESTAMPs للاستخدام العام - على سبيل المثال تخزين تاريخ الميلاد.

توضح الأمثلة أدناه كيف غير نوع التاريخ TIMESTAMP القيم بعد تغيير time-zone to 'america/new_york' حيث لم يتغير DATETIME.

mysql> show variables like '%time_zone%';
+------------------+---------------------+
| Variable_name    | Value               |
+------------------+---------------------+
| system_time_zone | India Standard Time |
| time_zone        | Asia/Calcutta       |
+------------------+---------------------+

mysql> create table datedemo(
    -> mydatetime datetime,
    -> mytimestamp timestamp
    -> );

mysql> insert into datedemo values ((now()),(now()));

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 14:11:09 |
+---------------------+---------------------+

mysql> set time_zone="america/new_york";

mysql> select * from datedemo;
+---------------------+---------------------+
| mydatetime          | mytimestamp         |
+---------------------+---------------------+
| 2011-08-21 14:11:09 | 2011-08-21 04:41:09 |
+---------------------+---------------------+

لقد حولت إجابتي إلى مقالة حتى يتمكن المزيد من الأشخاص من العثور على هذا مفيد ،MySQL: أنواع البيانات مقابل أنواع البيانات الزمنية.

الفرق الرئيسي هو أن DATETIME ثابت في حين يتأثر TIMESTAMP بإعداد time_zone.

لذلك ، لا يهم إلا عندما يكون لديك - أو ربما في المستقبل - مزامنة الكتل عبر المناطق الزمنية.

بعبارة أبسط: إذا كان لدي قاعدة بيانات في أستراليا ، وأخذت تفريغًا من قاعدة البيانات لمزامنة/نشر قاعدة بيانات في أمريكا ، فسيتم تحديث TIMESTAMP ليعكس الوقت الفعلي للحدث في المنطقة الزمنية الجديدة ، بينما لا يزال DATETIME يعكس وقت الحدث في منطقة التوقيت au .

هناك مثال رائع على DATETIME الذي يتم استخدامه حيث كان يجب استخدام TIMESTAMP في Facebook ، حيث لا تتأكد خوادمهم أبدًا تمامًا من الوقت الذي حدثت فيه الأشياء عبر المناطق الزمنية. ما إن كنت أجري محادثة في الوقت الذي قلت فيه أنني كنت أرد على الرسائل قبل إرسال الرسالة بالفعل. (هذا ، بالطبع ، ربما كان بسبب الترجمة السيئة للمنطقة الزمنية في برنامج المراسلة إذا تم نشر الأوقات بدلاً من مزامنتها.)

أنا أتخذ هذا القرار على أساس الدلالي.

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

يمكنني استخدام حقل التاريخ والوقت عندما يمكن تعيين التاريخ/الوقت وتغييره بشكل تعسفي. على سبيل المثال عندما يمكن للمستخدم حفظ مواعيد التغيير في وقت لاحق.

TIMESTAMP هو 4 بايت مقابل 8 بايت للتاريخ.

http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html

ولكن مثلما قال scronide إنه يوجد حد أدنى لعام 1970. إنه شيء رائع لأي شيء قد يحدث في المستقبل ؛)

أوصي باستخدام لا وقت أو حقل TIMESTAMP. إذا كنت ترغب في تمثيل يوم معين ككل (مثل عيد ميلاد) ، فاستخدم نوع DATE ، ولكن إذا كنت أكثر تحديداً من ذلك ، فمن المحتمل أن تكون مهتمًا بتسجيل لحظة فعلية بدلاً من وحدة من الوقت (اليوم ، الأسبوع ، الشهر ، السنة). بدلاً من استخدام DATETIME أو TIMESTAMP ، استخدم BIGINT ، وقم ببساطة بتخزين عدد المللي ثانية منذ Epoch (System.currentTimeMillis () إذا كنت تستخدم Java). هذا له العديد من المزايا:

1. يمكنك تجنب تأمين البائع. تدعم كل قاعدة بيانات عددًا صحيحًا بطريقة مماثلة نسبيًا. افترض أنك تريد الانتقال إلى قاعدة بيانات أخرى. هل تريد أن تقلق بشأن الاختلافات بين قيم DATETIME الخاصة بـ MySQL وكيف يعرّفها Oracle؟ حتى بين الإصدارات المختلفة من MySQL ، تتمتع TIMESTAMPS بمستوى مختلف من الدقة. لقد كان MySQL مؤخرًا يدعم الألفي ثانية في الطوابع الزمنية.
2. لا مشاكل المنطقة الزمنية. كان هناك بعض التعليقات الثاقبة هنا حول ما يحدث مع المناطق الزمنية مع أنواع البيانات المختلفة. لكن هل هذه معرفة مشتركة ، وهل سيستغرق زملاؤك في العمل كل الوقت لتعلمها؟ من ناحية أخرى ، من الصعب للغاية تغيير تغيير BigINT إلى Java.util.Date. يؤدي استخدام BIGINT إلى حدوث الكثير من المشكلات المتعلقة بالمناطق الزمنية على جانب الطريق.
3. لا تقلق بشأن النطاقات أو الدقة. لا داعي للقلق بشأن ما يتم اختصاره بنطاقات التاريخ في المستقبل (يذهب TIMESTAMP فقط إلى 2038).
4. تكامل أداة الجهة الخارجية. باستخدام عدد صحيح ، يكون تافهًا بالنسبة لأدوات الجهات الخارجية (مثل EclipseLink) للتفاعل مع قاعدة البيانات. لن يكون لدى كل أداة تابعة لجهة خارجية نفس الفهم "للوقت" كما يفعل MySQL. هل تريد المحاولة في Hibernate لمعرفة ما إذا كان يجب عليك استخدام كائن Java.sql.TimeStamp أو Java.util.Date إذا كنت تستخدم أنواع البيانات المخصصة هذه؟ استخدام أنواع البيانات الأساسية الخاصة بك يستفيد منها مع أدوات الجهات الخارجية البسيطة.

ترتبط هذه المشكلة ارتباطًا وثيقًا بكيفية تخزين قيمة الأموال (أي 1.99 دولار) في قاعدة البيانات. يجب عليك استخدام عشري أو نوع قاعدة البيانات Money أو الأسوأ من ذلك كله مزدوج؟ جميع هذه الخيارات 3 فظيعة ، للعديد من نفس الأسباب المذكورة أعلاه. يكمن الحل في تخزين قيمة المال بالسنتات باستخدام BIGINT ، ثم تحويل السنتات إلى دولارات عند عرض القيمة للمستخدم. مهمة قاعدة البيانات هي تخزين البيانات وليس تفسير تلك البيانات. كل أنواع البيانات الفاخرة هذه التي تراها في قواعد البيانات (خاصة Oracle) تضيف القليل ، وتبدأ في السير في طريق تأمين البائع.

1. TIMESTAMP أربعة بايت مقابل ثمانية بايت DATETIME.

2. الطوابع الزمنية هي أيضا أخف وزنا في قاعدة البيانات وفهرستها بشكل أسرع.

3. يتم استخدام نوع DATETIME عندما تحتاج إلى قيم تحتوي على معلومات التاريخ والوقت. يقوم MySQL باسترداد وعرض قيم DATETIME بتنسيق "YYYY-MM-DD HH: MM: SS". النطاق المدعوم هو "1000-01-01 00:00:00" إلى "9999-12-31 23:59:59".

يحتوي نوع بيانات TIMESTAMP على نطاق من "1970-01-01 00:00:01" UTC إلى "2038-01-09 03:14:07" UTC. له خصائص مختلفة ، اعتمادًا على إصدار MySQL ووضع SQL الذي يعمل عليه الخادم.

4. DATETIME ثابت بينما يتم TIMESTAMP بواسطة إعداد time_zone.

يعتمد على التطبيق ، حقا.

النظر في تعيين الطابع الزمني من قبل المستخدم إلى خادم في نيويورك ، للحصول على موعد في Sanghai. الآن عندما يتصل المستخدم في Sanghai ، فإنه يصل إلى نفس الطابع الزمني للموعد من خادم لها نسخ متطابقة في طوكيو. سوف يرى الموعد في طوكيو ، ويقابله وقت نيويورك الأصلي.

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

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

الطوابع الزمنية هي أيضا أخف وزنا في قاعدة البيانات وفهرستها بشكل أسرع.

2016 +: ما أنصحه هو ضبط منطقة توقيت Mysql على التوقيت العالمي المتفق عليه واستخدام DATETIME:

يمكن لأي إطار أمامي حديث (Angular 1/2 ، رد فعل ، Vue ، ...) أن يحول بسهولة وتوقيت وقت UTC إلى التوقيت المحلي.

بالإضافة إلى:

• يمكن أن يكون DATETIME الآن تلقائيًا تعيين إلى القيمة الزمنية الحالية كيف يمكنك تعيين قيمة افتراضية لعمود MySQL Datetime؟
• على عكس ما قد يظن المرء ، DATETIME هوأسرعTHAN TIMESTAMP ، http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs -int-performance-and-standarding-with-myisam/
• TIMESTAMP لا يزال محدودا إلى 1970-2038

(ما لم تكن من المحتمل تغيير المنطقة الزمنية للخوادم الخاصة بك)

مثال مع AngularJs

// back-end: format for angular within the sql query
SELECT DATE_FORMAT(my_datetime, "%Y-%m-%dT%TZ")...

// font-end Output the localised time
{{item.my_datetime | date :'medium' }}

كل تنسيق الوقت المترجم المتاح هنا: https://docs.angularjs.org/api/ng/filter/date

الحقل timestamp هو حالة خاصة للحقل datetime. يمكنك إنشاء أعمدة timestamp لخصائص خاصة ؛ يمكن تعيينه لتحديث نفسه إما على إنشاء و/أو التحديث.

في مصطلحات قاعدة البيانات "الأكبر" ، يحتوي timestamp على اثنين من مشغلات الحالات الخاصة.

ما هو الصحيح يعتمد كليا على ما تريد القيام به.

يكون TIMESTAMP دائمًا بالتوقيت العالمي المنسق (أي الثواني المنقضية منذ 1970-01-01 ، بالتوقيت العالمي المنسق) ، ويقوم خادم MySQL بتحويله تلقائيًا إلى التاريخ/الوقت لمنطقة الخادم الزمنية. على المدى الطويل ، TIMESTAMP هي الطريقة التي يجب عليك اتباعها لأنك تعلم أن بياناتك الزمنية ستكون دائمًا بالتوقيت العالمي المنسق. على سبيل المثال ، لن تقوم بربط التواريخ إذا قمت بالترحيل إلى خادم آخر أو إذا قمت بتغيير إعدادات المنطقة الزمنية على الخادم الخاص بك.

مقارنة بين DATETIME و TIMESTAMP و DATE

ما هذا [الكسر]؟

• يمكن أن تتضمن قيمة DATETIME أو TIMESTAMP جزءًا من أجزاء الثواني الكسرية الزائدة بدقة تصل إلى 6 ثوانٍ. على وجه الخصوص ، يتم تخزين أي جزء كسري في قيمة يتم إدخالها في عمود DATETIME أو TIMESTAMP بدلاً من تجاهلها. هذا بالطبع اختياري.

مصادر:

• MySQL مرجع أنواع بيانات التاريخ/الوقت
• مرجع متطلبات التخزين MySQL

تجدر الإشارة في MySQL إلى أنه يمكنك استخدام شيء ما على غرار ما يلي عند إنشاء أعمدة الجدول الخاص بك:

on update CURRENT_TIMESTAMP

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

كنت دائما استخدام الطابع الزمني يونيكس عند العمل مع MySQL و PHP. السبب الرئيسي لهذا هو الافتراضي التاريخ الطريقة في PHP يستخدم الطابع الزمني كمعلمة ، لذلك لن يكون هناك حاجة إلى تحليل.

للحصول على الطابع الزمني الحالي لـ Unix في PHP ، ما عليك سوى time();
وفي MySQL افعل SELECT UNIX_TIMESTAMP();.

من خلال تجربتي ، إذا كنت تريد حقل تاريخ يحدث فيه الإدراج مرة واحدة فقط ولا تريد أن يكون لديك أي تحديث أو أي إجراء آخر في هذا الحقل المحدد ، فانتقل إلى وقت التاريخ.

على سبيل المثال ، ضع في اعتبارك جدول user مع حقل REGISTRATION DATE. في هذا الجدول user ، إذا كنت تريد معرفة آخر تسجيل دخول في وقت مستخدم معين ، فانتقل إلى حقل timestamp type حتى يتم تحديث الحقل.

إذا كنت تقوم بإنشاء الجدول من phpMyAdmin ، فسيقوم الإعداد الافتراضي بتحديث الحقل الطابع الزمني عندما يحدث تحديث الصف. إذا لم يتم تحديث الطابع الزمني الخاص بك المقدم مع تحديث الصف ، فيمكنك استخدام الاستعلام التالي لإجراء تحديث تلقائي لحقل timestamp.

ALTER TABLE your_table
      MODIFY COLUMN ts_activity TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP;

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

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

لمزيد من التفاصيل ، يمكنك قراءة منشور المدونةTimestamp Vs Datetime.

احذر تغيير الطابع الزمني عند تنفيذ عبارة UPDATE على جدول. إذا كان لديك جدول يحتوي على أعمدة "الاسم" (varchar) و "Age" (int) و "Date_ Added" (الطابع الزمني) وقمت بتشغيل عبارة DML التالية

UPDATE table
SET age = 30

بعد ذلك ، سيتم تغيير كل قيمة مفردة في عمود "التاريخ_إضافة" إلى الطابع الزمني الحالي.

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

شيء آخر يستحق النظر:

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

المرجع مأخوذ من هذه المادة:

الاختلافات الرئيسية:

يستخدم TIMESTAMP لتتبع التغييرات على السجلات ، والتحديث في كل مرة يتم فيها تغيير السجل. يستخدم DATETIME لتخزين قيمة محددة وثابتة لا تتأثر بأي تغييرات في السجلات.

تتأثر TIMESTAMP أيضًا بالإعدادات المختلفة المتعلقة بـ TIME ZONE. التاريخ ثابت.

حولت TIMESTAMP المنطقة الزمنية الحالية داخليًا إلى UTC للتخزين ، وخلال الاسترجاع تم تحويلها مرة أخرى إلى المنطقة الزمنية الحالية. التاريخ لا يمكن القيام بذلك.

النطاق المدعوم TIMESTAMP: '1970-01-01 00:00:01 ′ UTC إلى' 2038-01-19 03:14:07 ′ نطاق التوقيت العالمي المدعوم بالتوقيت العالمي: '1000-01-01 00:00:00 ′ إلى' 9999 -12-31 23:59:59 ′

في حالتي ، قمت بتعيين التوقيت العالمي المتفق عليه (UTC) كمنطقة زمنية لكل شيء: النظام ، خادم قاعدة البيانات ، إلخ. في كل مرة أستطيع. إذا كان عميلي يحتاج إلى منطقة زمنية أخرى ، فقم بتهيئتها على التطبيق.

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

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

لذلك ، لتلخيص ، أقدر هذه المزايا للطابع الزمني:

• جاهز للاستخدام في التطبيقات الدولية (المنطقة الزمنية المتعددة)
• هجرات سهلة بين المناطق الزمنية
• من السهل جدًا حساب الاختلافات (فقط اطرح كلاً من الطوابع الزمنية)
• لا تقلق بشأن التواريخ في/خارج فترة زمنية الصيف

لكل هذه الأسباب ، اخترت UTC وحقول الطابع الزمني حيث ممكن. وأتجنب الصداع ؛)

لقد وجدت فائدة غير مسبوقة في قدرة TIMESTAMP على التحديث التلقائي نفسه استنادًا إلى الوقت الحالي دون استخدام مشغلات غير ضرورية. هذا مجرد أنا ، على الرغم من أن TIMESTAMP هو UTC كما قيل.

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

هناك اختلاف آخر بين Timestamp و Datetime في Timestamp لا يمكنك افتراض القيمة الافتراضية لـ NULL.

الفرق الرئيسي هو

• و INDEX على الطابع الزمني - الأعمال
• مؤشر INDEX الخاص بوقت التشغيل - لا يعمل

انظر إلى هذا المنشور لمعرفة مشاكل فهرسة Datetime

أفضّل استخدام الطابع الزمني حتى أبقي كل شيء في تنسيق أولي واحد مشترك وتنسيق البيانات في PHP أو في استعلام SQL الخاص بك. هناك حالات يكون فيها مفيدًا في التعليمات البرمجية للاحتفاظ بكل شيء في ثوانٍ عادية.

+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
|                                       TIMESTAMP                                       |                                 DATETIME                                 |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
| TIMESTAMP requires 4 bytes.                                                           | DATETIME requires 8 bytes.                                               |
| Timestamp is the number of seconds that have elapsed since January 1, 1970 00:00 UTC. | DATETIME is a text displays 'YYYY-MM-DD HH:MM:SS' format.                |
| TIMESTAMP supported range: ‘1970-01-01 00:00:01′ UTC to ‘2038-01-19 03:14:07′ UTC.    | DATETIME supported range: ‘1000-01-01 00:00:00′ to ‘9999-12-31 23:59:59′ |
| TIMESTAMP during retrieval converted back to the current time zone.                   | DATETIME can not do this.                                                |
| TIMESTAMP is used mostly for metadata i.e. row created/modified and audit purpose.    | DATETIME is used mostly for user-data.                                   |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+

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

$date  = $item['pubdate']; (etc ...)
$unix_now = time();
$result = strtotime($date, $unix_now);
$unix_diff_min = (($unix_now  - $result) / 60);
$min = round($unix_diff_min);

يتطلب TIMESTAMP 4 بايت ، بينما يتطلب DATETIME 8 بايت.

أنا مجرد استخدام BIGINT أثناء تخزين UTC ...

والتي بعد ذلك لا يزال من الممكن تعديلها بالتوقيت المحلي في PHP.

DATETIME ليتم تحديده مع FROM_UNIXTIME( integer_timestamp_column ).

من الواضح أنه يجب تعيين فهرس في هذا العمود ، وإلا لن يكون هناك تقدم.

لم يذكر حتى الآن ، هو أن DEFAULT CURRENT_TIMESTAMP يعمل فقط مع الطابع الزمني ، ولكن ليس حقول نوع DateTime.

يصبح هذا ملائمًا لجداول MS Access التي يمكنها فقط استخدام DateTime ولكن ليس Timestamp.

يكون TIMESTAMP مفيدًا عندما يكون لديك زوار من بلدان مختلفة مع مناطق زمنية مختلفة. يمكنك بسهولة تحويل TIMESTAMP إلى أي منطقة زمنية بلد

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

توقفت عن استخدام datetime في تطبيقاتي بعد مواجهة العديد من المشكلات والأخطاء المتعلقة بالمناطق الزمنية. IMHO باستخدام timestamp أفضل من datetime في معظم الحالات .

عندما تسأل ما هو الوقت؟ والإجابة تأتي كشيء مثل "2019-02-05 21:18:30" ، لم يكتمل ، ولم يتم تحديد إجابة لأنه يفتقر إلى جزء آخر ، في أي منطقة زمنية؟ واشنطن؟ موسكو؟ بكين؟

إن استخدام البيانات الزمنية دون المنطقة الزمنية يعني أن التطبيق الخاص بك يتعامل مع منطقة زمنية واحدة فقط ، ولكن الطوابع الزمنية تمنحك مزايا datetime بالإضافة إلى مرونة إظهار نفس نقطة التوقيت في مناطق زمنية مختلفة.

فيما يلي بعض الحالات التي ستجعلك تأسف باستخدام datetime وأتمنى أن تقوم بتخزين بياناتك في طوابع زمنية.

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

   SET time_zone = '+2:00';
   

2. قمت بتغيير البلد الذي تقيم فيه ، وتواصل عملك في الحفاظ على البيانات أثناء مشاهدتها في منطقة زمنية مختلفة (دون تغيير البيانات الفعلية).

3. تقبل بيانات من عملاء مختلفين حول العالم ، كل منهم يدرج الوقت في منطقته الزمنية.

بالمختصر

datetime = يدعم التطبيق منطقة زمنية واحدة (لكل من الإدراج والاختيار)

timestamp = يدعم التطبيق أي منطقة زمنية (لكل من الإدراج والاختيار)

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

إذا كنت ترغب في ضمان التطبيق الخاص بك لن يعمل في فبراير 2038 ، استخدم TIMESTAMP. ارجع إلى REFMAN لمعرفة نطاق التواريخ المدعومة.

الفرق بين DATETIME و TIMESTAMP

1. النطاق المدعم لـ DATETIME هو "1000-01-01 00:00:00" إلى "9999-12-31 23:59:59" بينما بالنسبة لـ TIMESTAMP ، يكون "1970-01-01 00:00:01" UTC إلى "2038-01-09 03:14:07" UTC.

2. قبل MySQL 5.6.4 ، يتطلب TIMESTAMP 4 بايت (+3 بايت للثواني الكسرية) لتخزين البيانات بينما يتطلب DATETIME 8 بايت (+3 بايت للثواني الكسرية).

3. اعتبارًا من MySQL 5.6.4 ، تتطلب DATETIME 5 بايت + 3 بايت إضافية لتخزين بيانات الثواني الكسرية.

   4. في MySQL5 + ، تحول قيمة TIMESTAMP من الوقت الحالي إلى التوقيت العالمي المتفق عليه والعكس بالعكس بينما DATETIME لا تقوم بأي تحويل.

4. يختلف TIMESTAMP مع إعدادات المنطقة الزمنية الحالية بينما يظل DATETIME ثابتًا. يمكن فهرسة بيانات TIMESTAMP بينما لا يمكن لبيانات DATETIME.

5. لن يتم تخزين الاستعلامات ذات DATETIME مؤقتًا ولكن سيتم تخزين الاستعلامات ذات TIMESTAMP في ذاكرة التخزين المؤقت.

timestamp هو الوقت الحالي لحدث مسجل بواسطة كمبيوتر من خلال Network Time Protocol (NTP) .

datetime هي المنطقة الزمنية الحالية التي تم تعيينها فيPHPالتكوين الخاص بك.