Tôi nên sử dụng kiểu dữ liệu datetime hay dấu thời gian trong MySQL?

Bạn có khuyên bạn nên sử dụng datetime hoặc trường dấu thời gian và tại sao (sử dụng MySQL)?

Tôi đang làm việc với PHP ở phía máy chủ.

Dấu thời gian trong MySQL thường được sử dụng để theo dõi các thay đổi đối với bản ghi và thường được cập nhật mỗi khi bản ghi được thay đổi. Nếu bạn muốn lưu trữ một giá trị cụ thể, bạn nên sử dụng trường datetime.

Nếu bạn có nghĩa là bạn muốn quyết định giữa việc sử dụng dấu thời gian UNIX hoặc trường thời gian MySQL gốc, hãy đi với định dạng gốc. Bạn có thể thực hiện các phép tính trong MySQL theo cách đó ("SELECT DATE_ADD(my_datetime, INTERVAL 1 DAY)")và thật đơn giản để thay đổi định dạng của giá trị thành dấu thời gian UNIX ("SELECT UNIX_TIMESTAMP(my_datetime)")khi bạn truy vấn bản ghi nếu bạn muốn thao tác với nó bằng PHP.

Trong MySQL 5 trở lên, các giá trị TIMESTAMP được chuyển đổi từ múi giờ hiện tại sang UTC để lưu trữ và được chuyển đổi trở lại từ UTC sang múi giờ hiện tại để truy xuất. (Điều này chỉ xảy ra đối với loại dữ liệu TIMESTAMP và không xảy ra đối với các loại khác như DATETIME.)

Theo mặc định, múi giờ hiện tại cho mỗi kết nối là thời gian của máy chủ. Múi giờ có thể được đặt trên cơ sở mỗi kết nối, như được mô tả trong Hỗ trợ múi giờ của máy chủ MySQL .

Tôi luôn sử dụng các trường DATETIME cho bất kỳ thứ gì ngoài siêu dữ liệu hàng (ngày được tạo hoặc sửa đổi).

Như đã đề cập trong tài liệu MySQL:

Loại DATETIME được sử dụng khi bạn cần các giá trị chứa cả thông tin ngày và thời gian. MySQL truy xuất và hiển thị các giá trị DATETIME ở định dạng 'YYYY-MM-DD HH: MM: SS'. Phạm vi được hỗ trợ là '1000-01-01 00:00:00' đến '9999-12-31 23:59:59'.

...

Kiểu dữ liệu TIMESTAMP có phạm vi từ '1970-01-01 00:00:01' UTC đến '2038-01-09 03:14:07' UTC. Nó có các thuộc tính khác nhau, tùy thuộc vào phiên bản MySQL và chế độ SQL mà máy chủ đang chạy.

Bạn hoàn toàn có khả năng đạt giới hạn thấp hơn trên TIMESTAMPs trong sử dụng chung - ví dụ: lưu trữ ngày sinh.

Các ví dụ dưới đây cho thấy TIMESTAMPloại ngày thay đổi các giá trị sau khi thay đổi vị time-zone to 'america/new_york'trí DATETIMEkhông thay đổi.

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

Tôi đã chuyển đổi câu trả lời của mình thành bài viết để nhiều người có thể tìm thấy loại dữ liệu hữu ích này : MySQL: Datetime Versus Timestamp .

Sự khác biệt chính là DATETIME không đổi trong khi TIMESTAMP bị ảnh hưởng bởi time_zonecài đặt.

Vì vậy, nó chỉ quan trọng khi bạn có - hoặc có thể trong tương lai có - các cụm được đồng bộ hóa theo các múi giờ.

Nói một cách đơn giản hơn: Nếu tôi có cơ sở dữ liệu ở Úc và lấy một cơ sở dữ liệu đó để đồng bộ hóa / điền vào cơ sở dữ liệu ở Mỹ, thì TIMESTAMP sẽ cập nhật để phản ánh thời gian thực của sự kiện trong múi giờ mới, trong khi đó, DATETIME sẽ vẫn phản ánh thời gian của sự kiện trong múi giờ au .

Một ví dụ tuyệt vời về việc sử dụng DATETIME trong đó TIMESTAMP nên được sử dụng là ở Facebook, nơi máy chủ của họ không bao giờ chắc chắn những gì thời gian xảy ra trên các múi giờ. Khi tôi đang có một cuộc trò chuyện trong đó thời gian nói rằng tôi đang trả lời tin nhắn trước khi tin nhắn thực sự được gửi. (Tất nhiên, điều này cũng có thể đã được gây ra bởi bản dịch múi giờ xấu trong phần mềm nhắn tin nếu thời gian được đăng chứ không phải đồng bộ hóa.)

Tôi đưa ra quyết định này trên cơ sở ngữ nghĩa.

Tôi sử dụng dấu thời gian khi tôi cần ghi lại thời điểm cố định (nhiều hơn hoặc ít hơn). Ví dụ: khi một bản ghi được chèn vào cơ sở dữ liệu hoặc khi một số hành động của người dùng diễn ra.

Tôi sử dụng trường datetime khi ngày / giờ có thể được đặt và thay đổi tùy ý. Ví dụ khi người dùng có thể lưu các cuộc hẹn thay đổi sau này.

Tôi khuyên bạn không nên sử dụng trường DATETIME hoặc TIMESTAMP. Nếu bạn muốn đại diện cho một ngày cụ thể (như sinh nhật), thì hãy sử dụng loại DATE, nhưng nếu bạn cụ thể hơn thế, có lẽ bạn thích ghi lại một khoảnh khắc thực tế trái ngược với một đơn vị thời gian (ngày, tuần, tháng, năm). Thay vì sử dụng DATETIME hoặc TIMESTAMP, hãy sử dụng BIGINT và chỉ cần lưu trữ số mili giây kể từ epoch (System.cienTimeMillis () nếu bạn đang sử dụng Java). Điều này có một số lợi thế:

1. Bạn tránh bị khóa nhà cung cấp. Khá nhiều cơ sở dữ liệu hỗ trợ các số nguyên theo cách tương đối giống nhau. Giả sử bạn muốn chuyển sang cơ sở dữ liệu khác. Bạn có muốn lo lắng về sự khác biệt giữa các giá trị DATETIME của MySQL và cách Oracle định nghĩa chúng không? Ngay cả trong số các phiên bản khác nhau của MySQL, TIMESTAMPS có mức độ chính xác khác nhau. Chỉ mới gần đây, MySQL hỗ trợ mili giây trong dấu thời gian.
2. Không có vấn đề múi giờ. Có một số ý kiến ​​sâu sắc ở đây về những gì xảy ra với các múi giờ với các loại dữ liệu khác nhau. Nhưng đây có phải là kiến ​​thức phổ biến, và tất cả đồng nghiệp của bạn sẽ dành thời gian để tìm hiểu nó? Mặt khác, thật khó để thay đổi BigINT thành java.util.Date. Sử dụng BIGINT gây ra rất nhiều vấn đề với các múi giờ rơi bên đường.
3. Không phải lo lắng về phạm vi hoặc độ chính xác. Bạn không phải lo lắng về những gì bị cắt ngắn bởi các phạm vi ngày trong tương lai (TIMESTAMP chỉ đến năm 2038).
4. Tích hợp công cụ của bên thứ ba. Bằng cách sử dụng một số nguyên, việc các công cụ của bên thứ 3 (ví dụ EclipseLink) giao tiếp với cơ sở dữ liệu là chuyện nhỏ. Không phải mọi công cụ của bên thứ ba sẽ có cùng cách hiểu về "datetime" như MySQL. Muốn thử và tìm hiểu trong Hibernate xem bạn nên sử dụng đối tượng java.sql.TimeStamp hoặc java.util.Date nếu bạn đang sử dụng các loại dữ liệu tùy chỉnh này? Sử dụng các loại dữ liệu cơ sở của bạn giúp việc sử dụng với các công cụ của bên thứ 3 trở nên tầm thường.

Vấn đề này liên quan chặt chẽ đến việc bạn nên lưu trữ giá trị tiền như thế nào (ví dụ $ 1.99) trong cơ sở dữ liệu. Bạn có nên sử dụng loại Tiền thập phân hoặc loại tiền của cơ sở dữ liệu hoặc tệ nhất trong tất cả số tiền gấp đôi? Cả 3 tùy chọn này đều rất tệ, vì nhiều lý do tương tự được liệt kê ở trên. Giải pháp là lưu trữ giá trị của tiền bằng xu bằng BIGINT, sau đó chuyển đổi xu sang đô la khi bạn hiển thị giá trị cho người dùng. Công việc của cơ sở dữ liệu là lưu trữ dữ liệu và KHÔNG truyền dữ liệu đó. Tất cả các kiểu dữ liệu ưa thích mà bạn thấy trong cơ sở dữ liệu (đặc biệt là Oracle) thêm rất ít và bắt đầu cho bạn đến với nhà cung cấp khóa.

TIMESTAMP là 4 byte Vs 8 byte cho DATETIME.

http://dev.mysql.com/doc/refman/5.0/en/st Storage-request.html

Nhưng giống như scronide nói rằng nó có giới hạn thấp hơn của năm 1970. Thật tuyệt vời cho bất cứ điều gì có thể xảy ra trong tương lai;)

1. TIMESTAMP là bốn byte so với tám byte cho DATETIME.

2. Dấu thời gian cũng nhẹ hơn trên cơ sở dữ liệu và được lập chỉ mục nhanh hơn.

3. Loại DATETIME được sử dụng khi bạn cần các giá trị chứa cả thông tin ngày và thời gian. MySQL truy xuất và hiển thị các giá trị DATETIME ở định dạng 'YYYY-MM-DD HH: MM: SS'. Phạm vi được hỗ trợ là '1000-01-01 00:00:00 đến' 9999-12-31 23:59:59.

Kiểu dữ liệu TIMESTAMP có phạm vi '1970-01-01 00:00:01 UTC đến' 2038-01-09 03:14:07 UTC. Nó có các thuộc tính khác nhau, tùy thuộc vào phiên bản MySQL và chế độ SQL mà máy chủ đang chạy.

4. DATETIME không đổi trong khi TIMESTAMP được thực hiện bằng cài đặt time_zone.

Phụ thuộc vào ứng dụng, thực sự.

Cân nhắc đặt dấu thời gian của người dùng đến máy chủ ở New York, để lấy hẹn ở Sanghai. Bây giờ khi người dùng kết nối ở Sanghai, anh ta truy cập cùng dấu thời gian cuộc hẹn từ một máy chủ được nhân đôi ở Tokyo. Anh ta sẽ thấy cuộc hẹn ở Tokyo, bù vào thời gian ban đầu ở New York.

Vì vậy, đối với các giá trị thể hiện thời gian của người dùng như cuộc hẹn hoặc lịch biểu, datetime sẽ tốt hơn. Nó cho phép người dùng kiểm soát ngày giờ chính xác mong muốn, bất kể cài đặt máy chủ. Thời gian đã đặt là thời gian đã đặt, không bị ảnh hưởng bởi múi giờ của máy chủ, múi giờ của người dùng hoặc bởi những thay đổi trong cách tính thời gian tiết kiệm ánh sáng ban ngày (vâng, nó thay đổi).

Mặt khác, đối với các giá trị thể hiện thời gian hệ thống như giao dịch thanh toán, sửa đổi bảng hoặc ghi nhật ký, luôn sử dụng dấu thời gian. Hệ thống sẽ không bị ảnh hưởng bằng cách di chuyển máy chủ sang múi giờ khác hoặc khi so sánh giữa các máy chủ theo các múi giờ khác nhau.

Dấu thời gian cũng nhẹ hơn trên cơ sở dữ liệu và được lập chỉ mục nhanh hơn.

2016 + : những gì tôi khuyên là đặt múi giờ Mysql của bạn thành UTC và sử dụng DATETIME:

Bất kỳ khung giao diện người dùng gần đây (Angular 1/2, Reac, Vue, ...) đều có thể dễ dàng và tự động chuyển đổi thời gian UTC của bạn sang giờ địa phương.

Ngoài ra:

• Giờ đây, DATETIME có thể được tự động đặt thành giá trị thời gian hiện tại Làm thế nào để bạn đặt giá trị mặc định cho cột Thời gian của MySQL?
• Trái với những gì người ta có thể nghĩ, DATETIME là FASTER THAN TIMESTAMP, http://gpshumano.bloss.dri.pt/2009/07/06/mysql-datetime-vs-timestamp-vs-int-performance-and-benchmarking-with -myisam /
• TIMESTAMP vẫn bị giới hạn trong 1970-2038

(Trừ khi bạn có khả năng thay đổi múi giờ của máy chủ của bạn)

Ví dụ với 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' }}

Tất cả định dạng thời gian được bản địa hóa có sẵn tại đây: https://docs.angularjs.org/api/ng/filter/date

Một timestamplĩnh vực là một trường hợp đặc biệt của datetimelĩnh vực này. Bạn có thể tạo timestampcác cột để có các thuộc tính đặc biệt; nó có thể được thiết lập để tự cập nhật khi tạo và / hoặc cập nhật.

Trong thuật ngữ cơ sở dữ liệu "lớn hơn", timestampcó một vài kích hoạt trường hợp đặc biệt trên đó.

Những gì đúng là hoàn toàn phụ thuộc vào những gì bạn muốn làm.

TIMESTAMP luôn ở trong UTC (nghĩa là đã trôi qua vài giây kể từ 1970-01-01, trong UTC) và máy chủ MySQL của bạn tự động chuyển đổi nó thành ngày / giờ cho múi giờ kết nối. Về lâu dài, TIMESTAMP là con đường để đi bởi vì bạn biết dữ liệu tạm thời của bạn sẽ luôn ở trong UTC. Ví dụ: bạn sẽ không làm hỏng ngày của mình nếu bạn di chuyển đến một máy chủ khác hoặc nếu bạn thay đổi cài đặt múi giờ trên máy chủ của mình.

Lưu ý: múi giờ kết nối mặc định là múi giờ của máy chủ, nhưng điều này có thể (nên) thay đổi mỗi phiên (xem SET time_zone = ...).

So sánh giữa DATETIME, TIMESTAMP và DATE

Đó là [.fraction] là gì?

• Giá trị DATETIME hoặc TIMESTAMP có thể bao gồm một phần giây phân đoạn kéo dài với độ chính xác lên đến micro giây (6 chữ số). Cụ thể, bất kỳ phần phân đoạn nào trong một giá trị được chèn vào cột DATETIME hoặc TIMESTAMP đều được lưu trữ thay vì bị loại bỏ. Tất nhiên đây là tùy chọn.

Nguồn:

• Tham chiếu kiểu dữ liệu Ngày / Giờ của MySQL
• Tham chiếu yêu cầu lưu trữ MySQL

Tôi sẽ luôn sử dụng dấu thời gian Unix khi làm việc với MySQL và PHP. Lý do chính cho việc này là phương thức ngày mặc định trong PHP sử dụng dấu thời gian làm tham số, do đó sẽ không cần phân tích cú pháp.

Để có được dấu thời gian Unix hiện tại trong PHP, chỉ cần làm time();
và trong MySQL làm SELECT UNIX_TIMESTAMP();.

Điều đáng chú ý trong MySQL, bạn có thể sử dụng một cái gì đó dọc theo các dòng bên dưới khi tạo các cột trong bảng của bạn:

on update CURRENT_TIMESTAMP

Điều này sẽ cập nhật thời gian tại mỗi trường hợp bạn sửa đổi một hàng và đôi khi rất hữu ích cho việc lưu trữ thông tin chỉnh sửa cuối cùng. Điều này chỉ hoạt động với dấu thời gian, không phải datetime.

Từ kinh nghiệm của tôi, nếu bạn muốn một trường ngày trong đó việc chèn chỉ xảy ra một lần và bạn không muốn có bất kỳ cập nhật hoặc bất kỳ hành động nào khác trên trường cụ thể đó, hãy đi với thời gian ngày .

Ví dụ: hãy xem xét một userbảng có trường NGÀY ĐĂNG KÝ . Trong userbảng đó , nếu bạn muốn biết thời gian đăng nhập cuối cùng của một người dùng cụ thể, hãy đi với một trường loại dấu thời gian để trường được cập nhật.

Nếu bạn đang tạo bảng từ phpMyAdmin , cài đặt mặc định sẽ cập nhật trường dấu thời gian khi cập nhật hàng xảy ra. Nếu dấu thời gian của bạn được gửi không cập nhật với cập nhật hàng, bạn có thể sử dụng truy vấn sau để tạo trường dấu thời gian được tự động cập nhật.

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

Kiểu dữ liệu dấu thời gian lưu trữ ngày và giờ, nhưng ở định dạng UTC, không phải ở định dạng múi giờ hiện tại như datetime. Và khi bạn tìm nạp dữ liệu, dấu thời gian lại chuyển đổi dữ liệu đó thành thời gian múi giờ hiện tại.

Vì vậy, giả sử bạn đang ở Hoa Kỳ và nhận dữ liệu từ máy chủ có múi giờ của Hoa Kỳ. Sau đó, bạn sẽ nhận được ngày và thời gian theo múi giờ Hoa Kỳ. Cột kiểu dữ liệu dấu thời gian luôn được cập nhật tự động khi hàng của nó được cập nhật. Vì vậy, nó có thể hữu ích để theo dõi khi một hàng cụ thể được cập nhật lần trước.

Để biết thêm chi tiết bạn có thể đọc bài viết trên blog Timestamp Vs Datetime .

Tôi luôn sử dụng dấu thời gian Unix, chỉ đơn giản là để duy trì sự tỉnh táo khi xử lý nhiều thông tin về thời gian, đặc biệt là khi thực hiện các điều chỉnh cho múi giờ, thêm / bớt ngày và tương tự. Khi so sánh dấu thời gian, điều này loại trừ các yếu tố phức tạp của múi giờ và cho phép bạn tiết kiệm tài nguyên trong xử lý phía máy chủ của bạn (Cho dù đó là mã ứng dụng hoặc truy vấn cơ sở dữ liệu) trong đó bạn sử dụng số học trọng lượng nhẹ thay vì cộng / trừ thời gian ngày nặng hơn chức năng.

Một điều đáng để xem xét:

Nếu bạn đang xây dựng một ứng dụng, bạn sẽ không bao giờ biết dữ liệu của mình có thể phải được sử dụng như thế nào. Nếu bạn kết thúc việc phải so sánh một loạt các bản ghi trong bộ dữ liệu của mình, với, giả sử, một loạt các mục từ API của bên thứ ba và nói, hãy đặt chúng theo thứ tự thời gian, bạn sẽ rất vui khi có Dấu thời gian Unix cho hàng của bạn. Ngay cả khi bạn quyết định sử dụng dấu thời gian của MySQL, hãy lưu trữ dấu thời gian Unix làm bảo hiểm.

Trong trường hợp của tôi, tôi đặt UTC làm múi giờ cho mọi thứ: hệ thống, máy chủ cơ sở dữ liệu, v.v. mỗi khi tôi có thể. Nếu khách hàng của tôi yêu cầu múi giờ khác, thì tôi sẽ định cấu hình nó trên ứng dụng.

Tôi hầu như luôn thích dấu thời gian hơn là trường thời gian, bởi vì dấu thời gian bao gồm cả múi giờ. Vì vậy, vì thời điểm ứng dụng sẽ được truy cập từ người dùng từ các múi giờ khác nhau và bạn muốn họ thấy ngày và giờ trong múi giờ địa phương của họ, loại trường này giúp bạn dễ dàng thực hiện hơn so với khi dữ liệu được lưu trong trường datetime .

Thêm vào đó, trong trường hợp di chuyển cơ sở dữ liệu sang hệ thống với múi giờ khác, tôi sẽ cảm thấy tự tin hơn khi sử dụng dấu thời gian. Không nói các vấn đề có thể xảy ra khi tính toán sự khác biệt giữa hai thời điểm với một số lần thay đổi thời gian ở giữa và cần độ chính xác từ 1 giờ trở xuống.

Vì vậy, để tóm tắt, tôi đánh giá cao lợi thế này của dấu thời gian:

• sẵn sàng sử dụng trên các ứng dụng quốc tế (nhiều múi giờ)
• di chuyển dễ dàng giữa các múi giờ
• khá dễ dàng để tính toán sự khác biệt (chỉ cần trừ cả hai dấu thời gian)
• không phải lo lắng về ngày vào / ra một khoảng thời gian mùa hè

Vì tất cả lý do này, tôi chọn các trường UTC & dấu thời gian nơi có thể nhìn thấy. Và tôi tránh đau đầu;)

Cảnh giác với dấu thời gian thay đổi khi bạn thực hiện câu lệnh CẬP NHẬT trên bảng. Nếu bạn có một bảng có các cột 'Tên' (varchar), 'Age' (int) và 'Date_Added' (dấu thời gian) và bạn chạy câu lệnh DML sau đây

UPDATE table
SET age = 30

sau đó, mọi giá trị trong cột 'Date_Added' của bạn sẽ được thay đổi thành dấu thời gian hiện tại.

Tài liệu tham khảo lấy từ Điều này:

Sự khác biệt chính:

TIMESTAMP được sử dụng để theo dõi các thay đổi đối với các bản ghi và cập nhật mỗi khi bản ghi được thay đổi. DATETIME được sử dụng để lưu trữ giá trị cụ thể và tĩnh không bị ảnh hưởng bởi bất kỳ thay đổi nào trong hồ sơ.

TIMESTAMP cũng bị ảnh hưởng bởi các cài đặt liên quan đến TIME ZONE khác nhau. Dữ liệu không đổi.

TIMESTAMP đã chuyển đổi nội bộ múi giờ hiện tại sang UTC để lưu trữ và trong quá trình truy xuất được chuyển đổi trở lại múi giờ hiện tại. Cơ sở dữ liệu không thể làm điều này.

Phạm vi được hỗ trợ TIMESTAMP: '1970-01-01 00:00:01 UTC đến' 2038-01-19 03:14:07 range Phạm vi được hỗ trợ của UTC DATETIME: '1000-01-01 00:00:00 đến' 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.                                   |
+---------------------------------------------------------------------------------------+--------------------------------------------------------------------------+

Một điểm khác biệt giữa Dấu thời gian và Thời gian là trong Dấu thời gian, bạn không thể đặt giá trị mặc định cho NULL.

Tôi thấy tính hữu dụng vượt trội trong khả năng tự động cập nhật của TIMESTAMP dựa trên thời gian hiện tại mà không cần sử dụng các kích hoạt không cần thiết. Mặc dù đó chỉ là tôi, mặc dù TIMESTAMP là UTC như đã nói.

Nó có thể theo dõi trên các múi giờ khác nhau, vì vậy nếu bạn cần hiển thị thời gian tương đối, thì thời gian UTC là những gì bạn muốn.

Sự khác biệt chính là

• một INDEX trên Dấu thời gian - hoạt động
• INDEX's on Datetime - Không hoạt động

nhìn vào bài đăng này để thấy các vấn đề với lập chỉ mục Datetime

Tôi đã ngừng sử dụng datetimetrong các ứng dụng của mình sau khi gặp nhiều vấn đề và lỗi liên quan đến múi giờ. IMHO sử dụng timestamptốt hơn datetimetrong hầu hết các trường hợp .

Khi bạn hỏi mấy giờ rồi? và câu trả lời giống như '2019-02-05 21:18:30', chưa hoàn thành, không được xác định câu trả lời vì nó thiếu một phần khác, trong múi giờ nào? Washington? Matxcơva? Bắc Kinh ?

Sử dụng thời gian không có múi giờ có nghĩa là ứng dụng của bạn chỉ xử lý 1 múi giờ, tuy nhiên dấu thời gian mang lại cho bạn những lợi ích của datetime cộng với tính linh hoạt của việc hiển thị cùng một thời điểm chính xác trong các múi giờ khác nhau.

Dưới đây là một số trường hợp sẽ khiến bạn hối hận khi sử dụng datetimevà ước rằng bạn đã lưu trữ dữ liệu của mình trong dấu thời gian.

1. Để khách hàng của bạn thoải mái, bạn muốn cho họ thấy thời gian dựa trên múi giờ ưa thích của họ mà không khiến họ phải làm toán và chuyển đổi thời gian sang múi giờ có ý nghĩa của họ. tất cả những gì bạn cần là thay đổi múi giờ và tất cả mã ứng dụng của bạn sẽ giống nhau. (Trên thực tế, bạn phải luôn xác định múi giờ khi bắt đầu ứng dụng hoặc yêu cầu xử lý trong trường hợp ứng dụng PHP)

   SET time_zone = '+2:00';

2. bạn đã thay đổi quốc gia bạn ở và tiếp tục công việc duy trì dữ liệu trong khi xem dữ liệu đó ở múi giờ khác (không thay đổi dữ liệu thực tế).

3. bạn chấp nhận dữ liệu từ các khách hàng khác nhau trên khắp thế giới, mỗi người trong số họ chèn thời gian vào múi giờ của mình.

Nói ngắn gọn

datetime = application hỗ trợ 1 múi giờ (cho cả chèn và chọn)

timestamp = ứng dụng hỗ trợ bất kỳ múi giờ nào (cho cả chèn và chọn)

Câu trả lời này chỉ dành cho việc làm nổi bật tính linh hoạt và dễ dàng của dấu thời gian khi nói đến múi giờ, nó không bao gồm bất kỳ sự khác biệt nào khác như kích thước hoặc phạm vi hoặc phân số cột .

Tôi thích sử dụng dấu thời gian để giữ mọi thứ ở một định dạng thô phổ biến và định dạng dữ liệu theo mã PHP hoặc trong truy vấn SQL của bạn. Có những trường hợp nó có ích trong mã của bạn để giữ mọi thứ trong vài giây.

A TIMESTAMPyêu cầu 4 byte, trong khi a DATETIMEyêu cầu 8 byte.

Tôi thích một dấu thời gian Unix, bởi vì bạn có thể chuyển đổi thành số và chỉ cần lo lắng về số lượng. Ngoài ra, bạn thêm / bớt và nhận thời lượng, vv Sau đó chuyển đổi kết quả thành Ngày ở bất kỳ định dạng nào. Mã này tìm ra bao nhiêu thời gian tính bằng phút trôi qua giữa dấu thời gian từ tài liệu và thời gian hiện tại.

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