ฉันควรใช้ชนิดข้อมูลวันที่และเวลาหรือข้อมูลประทับเวลาใน MySQL หรือไม่

คุณจะแนะนำให้ใช้วันที่และเวลาหรือการประทับเวลาฟิลด์และทำไม (ใช้ MySQL)?

ฉันทำงานกับ PHP ที่ฝั่งเซิร์ฟเวอร์

โดยทั่วไป Timestamps ใน MySQL จะใช้เพื่อติดตามการเปลี่ยนแปลงของระเบียนและมักจะมีการปรับปรุงทุกครั้งที่มีการเปลี่ยนแปลงระเบียน หากคุณต้องการเก็บค่าเฉพาะคุณควรใช้เขตข้อมูลวันที่และเวลา

หากคุณหมายถึงว่าคุณต้องการที่จะตัดสินใจว่าจะใช้การประทับเวลา UNIX หรือฟิลด์ datetime MySQL ดั้งเดิมให้ไปกับรูปแบบเนทิฟ คุณสามารถทำการคำนวณภายใน MySQL ด้วยวิธีนี้ ("SELECT DATE_ADD(my_datetime, INTERVAL 1 DAY)")และเปลี่ยนรูปแบบของค่าเป็น UNIX timestamp ได้ง่าย("SELECT UNIX_TIMESTAMP(my_datetime)")เมื่อคุณค้นหาระเบียนถ้าคุณต้องการใช้งานด้วย PHP

ใน MySQL 5 ขึ้นไปค่าTIMESTAMPจะถูกแปลงจากเขตเวลาปัจจุบันเป็น UTC เพื่อจัดเก็บและแปลงกลับจาก UTC เป็นโซนเวลาปัจจุบันเพื่อดึงข้อมูล (นี้เกิดขึ้นเฉพาะสำหรับชนิดข้อมูลการลงเวลาและไม่ได้ประเภทอื่น ๆ เช่น DATETIME.)

โดยค่าเริ่มต้นโซนเวลาปัจจุบันสำหรับการเชื่อมต่อแต่ละครั้งเป็นเวลาของเซิร์ฟเวอร์ โซนเวลาสามารถตั้งอยู่บนพื้นฐานต่อการเชื่อมต่อที่อธิบายไว้ในเซิร์ฟเวอร์โซนเวลาการสนับสนุน MySQL

ฉันมักจะใช้เขตข้อมูล 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 ที่เซิร์ฟเวอร์กำลังทำงาน

คุณมีแนวโน้มที่จะถึงขีด จำกัด ล่างของ TIMESTAMP ในการใช้งานทั่วไป - เช่นการจัดเก็บวันเกิด

ตัวอย่างด้านล่างแสดงให้เห็นว่า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 ยังสะท้อนให้เห็นถึงเวลาของเหตุการณ์ในเขตเวลา

ตัวอย่างที่ดีของการใช้ DATETIME ที่ควรใช้ TIMESTAMP ใน Facebook ซึ่งเซิร์ฟเวอร์ของพวกเขาไม่แน่ใจว่าสิ่งใดที่เกิดขึ้นในเขตเวลา เมื่อผมได้มีการสนทนาในเวลาที่บอกว่าผมได้รับการตอบกลับข้อความก่อนที่ข้อความถูกส่งจริง (แน่นอนว่าสิ่งนี้อาจเกิดจากการแปลโซนเวลาที่ไม่ดีในซอฟต์แวร์การส่งข้อความหากมีการโพสต์เวลาแทนการซิงโครไนซ์)

ฉันตัดสินใจบนฐานความหมาย

ฉันใช้การประทับเวลาเมื่อฉันต้องการบันทึกจุดคงที่ (มากหรือน้อย) ในเวลา ตัวอย่างเช่นเมื่อมีการแทรกบันทึกลงในฐานข้อมูลหรือเมื่อมีการกระทำของผู้ใช้เกิดขึ้น

ฉันใช้ฟิลด์ datetime เมื่อสามารถตั้งค่าและเปลี่ยนวันที่ / เวลาได้ตามใจชอบ ตัวอย่างเช่นเมื่อผู้ใช้สามารถบันทึกการเปลี่ยนแปลงการนัดหมายในภายหลัง

ฉันขอแนะนำให้ใช้ทั้งฟิลด์ DATETIME หรือ TIMESTAMP หากคุณต้องการเป็นตัวแทนของวันใดวันหนึ่งโดยเฉพาะ (เช่นวันเกิด) ให้ใช้ประเภท DATE แต่ถ้าคุณเจาะจงมากกว่านั้นคุณอาจสนใจบันทึกช่วงเวลาที่เกิดขึ้นจริงซึ่งตรงข้ามกับหน่วยของ เวลา (วัน, สัปดาห์, เดือน, ปี) แทนที่จะใช้ DATETIME หรือ TIMESTAMP ให้ใช้ BIGINT และเพียงเก็บจำนวนมิลลิวินาทีนับตั้งแต่ยุค (System.currentTimeMillis () หากคุณใช้ Java) นี่มีข้อดีหลายประการ:

1. คุณหลีกเลี่ยงการล็อคอินของผู้ขาย ค่อนข้างทุกฐานข้อมูลรองรับจำนวนเต็มในรูปแบบที่ค่อนข้างคล้ายกัน สมมติว่าคุณต้องการย้ายไปยังฐานข้อมูลอื่น คุณต้องการกังวลเกี่ยวกับความแตกต่างระหว่างค่า DATETIME ของ MySQL และวิธีที่ Oracle กำหนดค่าเหล่านั้นหรือไม่ แม้ใน MySQL เวอร์ชันต่าง ๆ TIMESTAMPS ก็มีระดับความแม่นยำที่แตกต่างกัน เป็นเพียงเมื่อเร็ว ๆ นี้ที่ MySQL รองรับมิลลิวินาทีในการประทับเวลา
2. ไม่มีปัญหาเกี่ยวกับเขตเวลา มีการแสดงความคิดเห็นที่ลึกซึ้งเกี่ยวกับสิ่งที่เกิดขึ้นกับเขตเวลาด้วยประเภทข้อมูลที่แตกต่างกัน แต่นี่เป็นความรู้ทั่วไปและเพื่อนร่วมงานของคุณทุกคนจะใช้เวลาเรียนรู้หรือไม่? ในทางตรงกันข้ามมันค่อนข้างยากที่จะเกิดความสับสนในการเปลี่ยน BigINT ให้เป็น java.util.Date การใช้ BIGINT ทำให้เกิดปัญหามากมายเกี่ยวกับเขตเวลาที่จะตกอยู่ข้างทาง
3. ไม่ต้องกังวลเกี่ยวกับช่วงหรือความแม่นยำ คุณไม่ต้องกังวลเกี่ยวกับสิ่งที่ถูกตัดให้สั้นลงตามช่วงวันที่ในอนาคต (TIMESTAMP ไปที่ 2038 เท่านั้น)
4. การรวมเครื่องมือของบุคคลที่สาม โดยใช้จำนวนเต็มมันเป็นเรื่องเล็กน้อยสำหรับเครื่องมือของบุคคลที่สาม (เช่น EclipseLink) เพื่อเชื่อมต่อกับฐานข้อมูล ไม่ใช่เครื่องมือของบุคคลที่สามทุกคนที่จะมีความเข้าใจเหมือนกันกับ "วันที่และเวลา" เช่นเดียวกับ MySQL ต้องการลองและคิดออกในไฮเบอร์เนตว่าคุณควรใช้วัตถุ java.sql.TimeStamp หรือ java.util.Date ถ้าคุณใช้ประเภทข้อมูลที่กำหนดเองเหล่านี้หรือไม่ การใช้ประเภทข้อมูลพื้นฐานของคุณทำให้การใช้งานกับเครื่องมืออื่น ๆ เป็นเรื่องเล็กน้อย

ปัญหานี้เกี่ยวข้องอย่างใกล้ชิดกับวิธีเก็บค่าเงิน (เช่น $ 1.99) ในฐานข้อมูล คุณควรใช้ทศนิยมหรือประเภทเงินของฐานข้อมูลหรือแย่ที่สุดของ Double ทั้งหมดหรือไม่ ทั้งสามตัวเลือกเหล่านี้แย่มากด้วยเหตุผลหลายประการที่กล่าวไว้ข้างต้น วิธีแก้ไขคือการเก็บค่าเงินเป็นเซ็นต์โดยใช้ BIGINT แล้วแปลงเซนต์เป็นดอลลาร์เมื่อคุณแสดงมูลค่าให้กับผู้ใช้ งานของฐานข้อมูลคือการจัดเก็บข้อมูลและไม่ให้บุกรุกข้อมูลนั้น ประเภทข้อมูลแฟนซีเหล่านี้ทั้งหมดที่คุณเห็นในฐานข้อมูล (โดยเฉพาะอย่างยิ่ง Oracle) เพิ่มเล็กน้อยและเริ่มต้นคุณสู่การล็อคอินผู้ขาย

TIMESTAMP คือ 4 ไบต์ Vs 8 ไบต์เป็นเวลา DATETIME

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

แต่เช่นเดียวกับ scronide บอกว่ามันมีขีด จำกัด ที่ต่ำกว่าของปี 1970 มันยอดเยี่ยมสำหรับทุกสิ่งที่อาจเกิดขึ้นในอนาคตแม้ว่า;)

1. TIMESTAMP คือสี่ไบต์เทียบกับแปดไบต์สำหรับ DATETIME

2. Timestamps ยังเบาในฐานข้อมูลและจัดทำดัชนีได้เร็วขึ้น

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 เขาเข้าถึงการนัดหมายเวลาเดียวกันจากเซิร์ฟเวอร์มิเรอร์ในโตเกียว เขาจะเห็นการนัดหมายในเวลาโตเกียวชดเชยจากเวลานิวยอร์กเดิม

ดังนั้นสำหรับค่าที่แสดงเวลาของผู้ใช้เช่นการนัดหมายหรือกำหนดเวลา datetime จะดีกว่า ช่วยให้ผู้ใช้สามารถควบคุมวันที่และเวลาที่ต้องการโดยไม่คำนึงถึงการตั้งค่าเซิร์ฟเวอร์ เวลาที่ตั้งไว้คือเวลาที่ตั้งไว้ไม่ได้รับผลกระทบจากเขตเวลาของเซิร์ฟเวอร์เขตเวลาของผู้ใช้หรือจากการเปลี่ยนแปลงวิธีคำนวณการประหยัดเวลาตามฤดูกาล (ใช่มีการเปลี่ยนแปลง)

ในทางกลับกันสำหรับค่าที่แสดงเวลาของระบบเช่นธุรกรรมการชำระเงินการแก้ไขตารางหรือการบันทึกให้ใช้การประทับเวลาเสมอ ระบบจะไม่ได้รับผลกระทบจากการย้ายเซิร์ฟเวอร์ไปยังโซนเวลาอื่นหรือเมื่อเปรียบเทียบระหว่างเซิร์ฟเวอร์ในเขตเวลาที่แตกต่างกัน

Timestamps ยังเบาในฐานข้อมูลและจัดทำดัชนีได้เร็วขึ้น

2016 + : สิ่งที่ฉันแนะนำคือการตั้งค่าเขตเวลา Mysql ของคุณเป็น UTC และใช้ DATETIME:

เฟรมเวิร์กส่วนหน้าล่าสุด (Angular 1/2, react, Vue, ... ) สามารถแปลง datetime UTC ของคุณเป็นเวลาท้องถิ่นและอัตโนมัติ

นอกจากนี้:

• DATETIME สามารถตั้งค่าเวลาปัจจุบันได้โดยอัตโนมัติคุณจะตั้งค่าเริ่มต้นสำหรับคอลัมน์ MySQL Datetime ได้อย่างไร
• ตรงกันข้ามกับสิ่งที่เราคิด DATETIME เร็วกว่าการตั้งเวลา http://gpshumano.blogs.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-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 อยู่ใน UTC เสมอ (นั่นคือวินาทีที่ผ่านไปตั้งแต่ 1970-01-01 ใน UTC) และเซิร์ฟเวอร์ MySQL ของคุณจะแปลงเป็นวันที่ / เวลาสำหรับเขตเวลาการเชื่อมต่อโดยอัตโนมัติ ในระยะยาว TIMESTAMP เป็นหนทางไปเพราะคุณรู้ว่าข้อมูลทางโลกของคุณจะอยู่ใน UTC เสมอ ตัวอย่างเช่นคุณจะไม่พลาดวันที่ถ้าคุณย้ายไปที่เซิร์ฟเวอร์อื่นหรือหากคุณเปลี่ยนการตั้งค่าเขตเวลาในเซิร์ฟเวอร์ของคุณ

หมายเหตุ: เขตเวลาการเชื่อมต่อเริ่มต้นคือเขตเวลาของเซิร์ฟเวอร์ แต่สิ่งนี้สามารถ (ควร) เปลี่ยนแปลงในแต่ละเซสชัน (ดูSET time_zone = ...)

การเปรียบเทียบระหว่าง DATETIME, TIMESTAMP และ DATE

[.fraction] คืออะไร

• ค่า DATETIME หรือ TIMESTAMP สามารถรวมส่วนของเศษเสี้ยววินาทีต่อท้ายในความแม่นยำสูงถึง microseconds (6 หลัก) โดยเฉพาะอย่างยิ่งส่วนที่เป็นเศษส่วนใด ๆ ในค่าที่แทรกลงในคอลัมน์ DATETIME หรือ TIMESTAMP จะถูกเก็บไว้แทนที่จะถูกทิ้ง แน่นอนว่าเป็นตัวเลือก

แหล่งที่มา:

• การอ้างอิงชนิดข้อมูล MySQL วันที่ / เวลา
• การอ้างอิงข้อกำหนดในการจัดเก็บ MySQL

ฉันมักจะใช้เวลา Unix เมื่อทำงานกับ MySQL และ PHP เหตุผลหลักในการนี้เป็นวิธีวันที่เริ่มต้นใน PHP ใช้การประทับเวลาเป็นพารามิเตอร์ดังนั้นจึงไม่จำเป็นต้องแยกวิเคราะห์

ที่จะได้รับการประทับเวลา Unix ในปัจจุบัน PHP, เพียงแค่ทำtime();
และ MySQL SELECT UNIX_TIMESTAMP();ทำ

เป็นที่น่าสังเกตใน MySQL คุณสามารถใช้บางสิ่งบางอย่างตามบรรทัดด้านล่างเมื่อสร้างคอลัมน์ตารางของคุณ:

on update CURRENT_TIMESTAMP

การดำเนินการนี้จะอัปเดตเวลาในแต่ละอินสแตนซ์ที่คุณแก้ไขแถวและบางครั้งก็มีประโยชน์มากสำหรับข้อมูลการแก้ไขล่าสุดที่เก็บไว้ ใช้งานได้กับการประทับเวลาเท่านั้นไม่ใช่วันที่และเวลา

จากประสบการณ์ของผมถ้าคุณต้องการข้อมูลวันที่ในการแทรกซึ่งเกิดขึ้นเพียงครั้งเดียวและคุณไม่ต้องการที่จะมีการปรับปรุงใด ๆ หรือกระทำการใด ๆ บนสนามที่เฉพาะเจาะจงไปกับวันเวลา

ตัวอย่างเช่นพิจารณาuserตารางที่มีฟิลด์วันที่ลงทะเบียน ในuserตารางนั้นหากคุณต้องการทราบเวลาการเข้าสู่ระบบครั้งสุดท้ายของผู้ใช้รายใดให้ไปที่ฟิลด์ประเภทการประทับเวลาเพื่อให้ฟิลด์ได้รับการอัปเดต

หากคุณกำลังสร้างตารางจากphpMyAdminการตั้งค่าเริ่มต้นจะอัปเดตฟิลด์เวลาประทับเมื่อมีการอัปเดตแถวเกิดขึ้น หากการประทับเวลาของคุณไม่ได้รับการอัพเดตด้วยการอัพเดตแถวคุณสามารถใช้แบบสอบถามต่อไปนี้เพื่อให้ฟิลด์การประทับเวลาได้รับการอัปเดตอัตโนมัติ

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

ชนิดข้อมูลประทับเวลาเก็บวันที่และเวลา แต่ในรูปแบบ UTC ไม่ใช่ในรูปแบบเขตเวลาปัจจุบันเช่นเดียวกับวันที่และเวลา และเมื่อคุณดึงข้อมูลการประทับเวลาอีกครั้งจะแปลงเป็นเวลาเขตเวลาปัจจุบัน

สมมติว่าคุณอยู่ในสหรัฐอเมริกาและรับข้อมูลจากเซิร์ฟเวอร์ที่มีเขตเวลาของสหรัฐอเมริกา จากนั้นคุณจะได้รับวันที่และเวลาตามเขตเวลาของสหรัฐอเมริกา คอลัมน์ชนิดข้อมูลประทับเวลาจะได้รับการอัปเดตโดยอัตโนมัติทุกครั้งที่มีการอัปเดตแถว ดังนั้นจึงเป็นประโยชน์ในการติดตามเมื่อแถวที่เฉพาะเจาะจงได้รับการปรับปรุงครั้งล่าสุด

สำหรับรายละเอียดเพิ่มเติมคุณสามารถอ่านบล็อกโพสต์ประทับเวลา Vs วันที่และเวลา

ฉันมักจะใช้การประทับเวลา Unix เพียงเพื่อรักษาสติเมื่อจัดการกับข้อมูลวันที่และเวลาจำนวนมากโดยเฉพาะอย่างยิ่งเมื่อทำการปรับเปลี่ยนสำหรับเขตเวลาการเพิ่ม / การลบวันและสิ่งที่ชอบ เมื่อเปรียบเทียบการประทับเวลาสิ่งนี้ไม่รวมปัจจัยที่ซับซ้อนของเขตเวลาและช่วยให้คุณสามารถสำรองทรัพยากรในการประมวลผลฝั่งเซิร์ฟเวอร์ของคุณ (ไม่ว่าจะเป็นรหัสแอปพลิเคชันหรือแบบสอบถามฐานข้อมูล) ในกรณีที่คุณใช้การคำนวณทางคณิตศาสตร์น้ำหนักเบา ฟังก์ชั่น.

อีกสิ่งที่ควรพิจารณา:

หากคุณกำลังสร้างแอปพลิเคชันคุณจะไม่มีทางรู้ว่าข้อมูลของคุณจะต้องถูกนำไปใช้อย่างไร หากคุณต้องพูดพูดเปรียบเทียบบันทึกจำนวนมากในชุดข้อมูลของคุณด้วยพูดรายการมากมายจาก API ของบุคคลที่สามแล้วพูดว่าวางลำดับตามลำดับคุณจะมีความสุขที่ได้ Unix timestamps สำหรับแถวของคุณ แม้ว่าคุณจะตัดสินใจที่จะใช้การประทับเวลา MySQL ให้เก็บการประทับเวลาของ Unix ไว้เป็นประกัน

ในกรณีของฉันฉันตั้ง UTC เป็นเขตเวลาสำหรับทุกสิ่ง: ระบบเซิร์ฟเวอร์ฐานข้อมูลและอื่น ๆ ทุกครั้งที่ฉันทำได้ หากลูกค้าของฉันต้องการโซนเวลาอื่นฉันจะกำหนดค่าในแอพ

ฉันมักจะชอบการประทับเวลามากกว่าเขตข้อมูลวันที่เพราะการประทับเวลารวมถึงเขตเวลาโดยปริยาย ดังนั้นตั้งแต่วินาทีที่แอปจะสามารถเข้าถึงได้จากผู้ใช้จากเขตเวลาที่แตกต่างกันและคุณต้องการให้พวกเขาเห็นวันที่และเวลาในเขตเวลาท้องถิ่นของพวกเขาประเภทของเขตข้อมูลนี้ทำให้มันง่ายที่จะทำมากกว่าถ้าบันทึกข้อมูลในเขตข้อมูล .

ในกรณีของการย้ายฐานข้อมูลไปยังระบบที่มีเขตเวลาอื่นฉันจะรู้สึกมั่นใจมากขึ้นเมื่อใช้การประทับเวลา ไม่ต้องพูดปัญหาที่เป็นไปได้เมื่อคำนวณความแตกต่างระหว่างสองช่วงเวลาด้วยการเปลี่ยนเวลาสุเมเรียนในระหว่างและต้องการความแม่นยำ 1 ชั่วโมงหรือน้อยกว่า

ดังนั้นเพื่อสรุปฉันให้ความสำคัญกับข้อดีของการประทับเวลานี้:

• พร้อมที่จะใช้กับแอพสากล (โซนเวลาหลายเขต)
• การโยกย้ายง่ายระหว่างเขตเวลา
• ค่อนข้างง่ายในการคำนวณความแตกต่าง (เพียงลบการประทับเวลาทั้งสอง)
• ไม่ต้องกังวลเกี่ยวกับวันที่เข้า / ออกในช่วงฤดูร้อน

ด้วยเหตุผลทั้งหมดนี้ฉันเลือกฟิลด์ UTC และเวลาประทับที่เป็นไปได้ และฉันหลีกเลี่ยงอาการปวดหัว;)

ระวังการเปลี่ยนเวลาประทับเมื่อคุณทำคำสั่ง UPDATE บนโต๊ะ หากคุณมีตารางที่มีคอลัมน์ 'ชื่อ' (varchar), 'อายุ' (int) และ 'Date_Added' (การประทับเวลา) และคุณเรียกใช้คำสั่ง DML ต่อไปนี้

UPDATE table
SET age = 30

จากนั้นทุกค่าเดียวในคอลัมน์ 'Date_Added' ของคุณจะเปลี่ยนเป็นการประทับเวลาปัจจุบัน

การอ้างอิงที่นำมาจากบทความนี้:

ความแตกต่างหลัก:

TIMESTAMP ใช้เพื่อติดตามการเปลี่ยนแปลงของระเบียนและอัปเดตทุกครั้งเมื่อมีการเปลี่ยนแปลงบันทึก DATETIME ใช้เพื่อเก็บค่าเฉพาะและค่าคงที่ซึ่งไม่ได้รับผลกระทบจากการเปลี่ยนแปลงใด ๆ ในระเบียน

TIMESTAMP ยังได้รับผลกระทบจากการตั้งค่าที่เกี่ยวข้องกับ TIME ZONE DATETIME คงที่

TIMESTAMP แปลงโซนเวลาปัจจุบันภายในเป็น UTC สำหรับจัดเก็บข้อมูลและในระหว่างการดึงข้อมูลแปลงกลับเป็นโซนเวลาปัจจุบัน DATETIME ไม่สามารถทำได้

TIMESTAMP รองรับช่วง: '1970-01-01 00:00:01′ UTC ถึง '2038-01-19 03:14:07 :07 UTC DATETIME รองรับช่วง:' 1000-01-01 00:00:00 ′ถึง' 9999 -12-31 23:59:59 ′

+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+
|                                       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.                                   |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+

ข้อแตกต่างอื่นระหว่างการประทับเวลาและวันที่และเวลาอยู่ในการประทับเวลาคุณไม่สามารถค่าเริ่มต้นเป็น NULL ได้

ฉันพบประโยชน์ที่ไม่มีใครเทียบในความสามารถของ TIMESTAMP ในการอัปเดตอัตโนมัติตามเวลาปัจจุบันโดยไม่ต้องใช้ทริกเกอร์ที่ไม่จำเป็น นั่นเป็นเพียงฉันแม้ว่า TIMESTAMP เป็น UTC อย่างที่พูดไว้

มันสามารถติดตามข้ามเขตเวลาที่แตกต่างกันดังนั้นหากคุณต้องการแสดงเวลาที่สัมพันธ์กันเช่นเวลา UTC เป็นสิ่งที่คุณต้องการ

ความแตกต่างที่สำคัญคือ

• INDEX บน Timestamp - ได้ผล
• ดัชนีของ INDEX ใน Datetime - ไม่ทำงาน

ดูที่โพสต์นี้เพื่อดูปัญหาเกี่ยวกับการทำดัชนี Datetime

ฉันหยุดใช้งานdatetimeในแอปพลิเคชันของฉันหลังจากประสบปัญหาและข้อบกพร่องมากมายที่เกี่ยวข้องกับเขตเวลา IMHO ใช้timestampจะดีกว่าdatetimeในส่วนของกรณีที่

เมื่อคุณถามเวลาอะไร และคำตอบนั้นมาในรูปแบบ '2019-02-05 21:18:30' ที่ยังไม่เสร็จไม่ได้กำหนดคำตอบเพราะมันขาดอีกส่วนหนึ่งในเขตเวลาใด วอชิงตัน มอสโก ปักกิ่ง

การใช้ชุดข้อมูลที่ไม่มีเขตเวลาหมายความว่าแอปพลิเคชันของคุณจัดการกับเขตเวลาเพียง 1 เขตเท่านั้นอย่างไรก็ตามการประทับเวลาจะให้ประโยชน์แก่คุณdatetimeพร้อมความยืดหยุ่นในการแสดงจุดเวลาเดียวกันในเขตเวลาที่ต่างกัน

นี่คือบางกรณีที่จะทำให้คุณเสียใจที่ใช้งานdatetimeและต้องการให้คุณเก็บข้อมูลไว้ในการประทับเวลา

1. เพื่อความสะดวกสบายของลูกค้าคุณต้องการแสดงเวลาตามโซนเวลาที่ต้องการโดยไม่ต้องทำการคำนวณและแปลงเวลาเป็นเขตเวลาที่มีความหมาย สิ่งที่คุณต้องทำคือเปลี่ยนเขตเวลาและรหัสแอปพลิเคชันของคุณจะเหมือนกัน (ที่จริงแล้วคุณควรกำหนดเขตเวลาเมื่อเริ่มต้นแอปพลิเคชันหรือร้องขอการประมวลผลในกรณีที่แอปพลิเคชัน PHP)

   SET time_zone = '+2:00';

2. คุณเปลี่ยนประเทศที่คุณพำนักและดำเนินการบำรุงรักษาข้อมูลในขณะที่เห็นในเขตเวลาอื่น (โดยไม่ต้องเปลี่ยนข้อมูลจริง)

3. คุณยอมรับข้อมูลจากลูกค้าที่แตกต่างกันทั่วโลกแต่ละคนจะแทรกเวลาในเขตเวลาของเขา

ในระยะสั้น

datetime = แอปพลิเคชั่นสนับสนุน 1 เขตเวลา (สำหรับการแทรกและการเลือก)

timestamp = แอปพลิเคชันรองรับเขตเวลาใดก็ได้ (สำหรับการแทรกและการเลือก)

คำตอบนี้เป็นเพียงสำหรับการวางไฮไลท์บางอย่างเกี่ยวกับความยืดหยุ่นและความสะดวกในการประทับเวลาเมื่อมันมาถึงโซนเวลาจะไม่ครอบคลุมความแตกต่างอื่น ๆ เช่นขนาดคอลัมน์หรือช่วงหรือส่วน

ฉันชอบใช้การประทับเวลาดังนั้นเพื่อเก็บทุกอย่างไว้ในรูปแบบ raw ทั่วไปและจัดรูปแบบข้อมูลในรหัส PHP หรือในแบบสอบถาม SQL ของคุณ มีบางครั้งที่โค้ดของคุณมีประโยชน์ในการเก็บทุกสิ่งในไม่กี่วินาที

A TIMESTAMPต้องการ 4 ไบต์ในขณะที่ a DATETIMEต้องการ 8 ไบต์

ฉันชอบ Unix Timestamp เพราะคุณสามารถแปลงเป็นตัวเลขและเพียงแค่กังวลเกี่ยวกับตัวเลข รวมถึงคุณเพิ่ม / ลบและรับระยะเวลา ฯลฯ จากนั้นแปลงผลลัพธ์เป็น Date ในรูปแบบใดก็ได้ รหัสนี้ค้นหาจำนวนเวลาเป็นนาทีที่ส่งผ่านระหว่างการประทับเวลาจากเอกสารและเวลาปัจจุบัน

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