Câu hỏi Tôi có nên sử dụng kiểu dữ liệu datetime hoặc dấu thời gian trong MySQL không?


Bạn có khuyên bạn nên sử dụng ngày giờ hoặc một dấu thời gian lĩnh vực, và tại sao (sử dụng MySQL)?

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


2304
2018-01-03 16:14


gốc


điều này có một số thông tin liên quan codeproject.com/Tips/1215635/MySQL-DATETIME-vs-TIMESTAMP - Waqleh


Các câu trả lời:


Dấu thời gian trong MySQL thường được sử dụng để theo dõi các thay đổi đối với các 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 datetime gốc của MySQL, 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à đơn giản là 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 vận hành nó với PHP.


1559
2018-01-03 16:26



Một sự khác biệt quan trọng là DATETIME đại diện cho một ngày (như được tìm thấy trong một lịch) và một thời gian (như có thể được quan sát trên đồng hồ treo tường), trong khi TIMESTAMP đại diện cho một điểm được xác định rõ ràng trong thời gian. Điều này có thể rất quan trọng nếu ứng dụng của bạn xử lý các múi giờ. Cách đây bao lâu là '2010-09-01 16:31:00'? Nó phụ thuộc vào múi giờ bạn đang ở. Đối với tôi nó chỉ là một vài giây trước, cho bạn nó có thể đại diện cho một thời gian trong tương lai. Nếu tôi nói 1283351460 giây từ '1970-01-01 00:00:00 UTC', bạn biết chính xác thời điểm tôi nói đến. (Xem câu trả lời tuyệt vời của Nir dưới đây). [Nhược điểm: phạm vi hợp lệ]. - MattBianco
Một khác biệt khác: các truy vấn có ngày giờ "gốc" sẽ không được lưu vào bộ nhớ cache, nhưng các truy vấn có dấu thời gian - sẽ là. - OZ_
"Dấu thời gian trong MySQL thường được sử dụng để theo dõi các thay đổi đối với hồ sơ" Đừng nghĩ đó là câu trả lời hay. Dấu thời gian mạnh hơn và phức tạp hơn nhiều so với MattBianco và Nir sayd. Mặc dù, phần thứ hai của câu trả lời là rất tốt. Đó là sự thật những gì blivet nói, và là một lời khuyên tốt. - santiagobasulto
Ngoài ra, 1 lưu ý quan trọng, DATETIME và TIMESTAMP có thể sử dụng CURRENT_TIMESTAMP, NOW () một cách tôn trọng vì nó là giá trị mặc định, nhưng ví dụ DATE không thể, vì nó sử dụng '0000-00-00' theo mặc định, để giải quyết vấn đề đó Kích hoạt của riêng bạn cho bảng đó, để chèn ngày hiện tại (không có thời gian) vào trường / col với kiểu DATE mysql. - Arthur Kushman
@DavidHarkness: Tài liệu nói "Để chỉ định các thuộc tính tự động, hãy sử dụng mệnh đề DEFAULT CURRENT_TIMESTAMP và ON UPDATE CURRENT_TIMESTAMP" dev.mysql.com/doc/refman/5.0/en/timestamp-initialization.html - Plap


Trong MySQL 5 trở lên, TIMESTAMP các giá trị được chuyển đổi từ múi giờ hiện tại sang UTC để lưu trữ và chuyển đổ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 phải cho 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ờ máy chủ MySQL.


816
2018-03-02 11:49



Nguồn: dev.mysql.com/doc/refman/5.1/en/datetime.html - Andy0708
bản trình bày OReilly này rất tốt cho chủ đề này (PDF xin lỗi) cdn.oreillystatic.com/en/assets/1/event/36/… - gcb
Nó cũng về bản chất của sự kiện: - Một hội nghị video (TIMESTAMP). Tất cả những người tham dự sẽ thấy một tham chiếu đến một thời gian tuyệt đối của thời gian được điều chỉnh theo múi giờ của nó. - Một thời gian nhiệm vụ địa phương (DATETIME), tôi nên làm nhiệm vụ này tại 2014/03/31 9:00 AM không có vấn đề nếu ngày hôm đó tôi đang làm việc ở New York hoặc Paris. Tôi sẽ bắt đầu làm việc lúc 8:00 sáng giờ địa phương, tôi sẽ là ngày hôm đó. - yucer
Vì vậy, nếu tôi THAY ĐỔI múi giờ của máy chủ, thì giá trị của TIMESTAMP sẽ vẫn giữ nguyên hoặc sẽ thay đổi quá ?? - Andrew
@Andrew vì nó là UTC, nó sẽ ở lại UTC. Tuy nhiên, chuyển đổi lạc hậu sẽ thay đổi múi giờ máy chủ "mới". - nembleton


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 tháng và thời gian. MySQL truy xuất và hiển thị các giá trị DATETIME trong định dạng HH: MM: SS 'YYYY-MM-DD. Phạm vi được hỗ trợ là '1000-01-01 00:00:00' đến '9999-12-31 23:59:59'.

...

Loại 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.

Bạn có khả năng đạt đến giới hạn dưới trên TIMESTAMPs nói chung - ví dụ: lưu trữ ngày sinh.


430
2018-01-04 04:26



bạn cũng có thể nhấn phía trên hạn chế dễ dàng nếu bạn đang ở ngân hàng hoặc bất động sản ... Thế chấp 30 năm vượt quá 2038 ngay bây giờ - Kip
Tất nhiên, sử dụng dấu thời gian Unix 64 bit. Ví dụ, trong Java, new Date().getTime() đã cung cấp cho bạn giá trị 64 bit. - osa
1 cho DATETIME: Trong luồng dữ liệu của chúng tôi, từ SQL Server của Cửa hàng vật lý để mua và hóa đơn, được chuyển đến Máy chủ MySQL cho Cửa hàng ảo trên trang web, DATETIME tốt hơn cho Ngày sửa đổi khi loại dữ liệu này tồn tại trong Giao dịch -SQL. Nhưng TIMESTAMP có nghĩa là điều khác trong Transact-SQL, nó là nhị phân như ROWVERSION, mặc dù MySQL TIMESTAMP là DateTime tương tự. Vì vậy, chúng tôi tránh việc sử dụng TIMESTAMP cho khả năng tương thích của hai DB. - jacouh
Không ý kiến. Đó là một vấn đề lớn hơn nhiều so với MySQL và không có cách khắc phục đơn giản: en.wikipedia.org/wiki/Year_2038_problem Tôi không tin rằng MySQL chỉ có thể khai báo dấu thời gian bây giờ là 64-bit và giả định mọi thứ sẽ ổn. Họ không kiểm soát phần cứng. - scronide
Ngày sinh có thể là DATETIME nếu bạn biết thời gian sinh, như tôi làm cho tôi. - Kris Craig


Các ví dụ dưới đây cho thấy cách TIMESTAMP loại ngày đã thay đổi các giá trị sau khi thay đổi time-zone to 'america/new_york' Ở đâu 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 hơn có thể thấy điều này hữu ích, MySQL: Thời gian so với Dấu thời gian Kiểu dữ liệu.


284
2017-08-21 08:45



Vâng, thực sự là DATETIME thay đổi thời gian hiệu quả với thay đổi múi giờ, TIMESTAMP đã không thay đổi nhưng đại diện của con người đã làm. - flindeberg
Có vẻ như lệnh này không hoạt động trong MySQL 5.6 set time_zone="america/new_york"; - Manjunath Reddy
Đây là câu trả lời cho vấn đề time_zone đã đặt. stackoverflow.com/questions/3451847/mysql-timezone-change - Manjunath Reddy
Đồng ý với @flindeberg. Dấu thời gian biểu thị thời gian chính xác, không phải datetime, sau khi thay đổi múi giờ - Nitin Bansal


Điểm khác biệt chính là DATETIME là hằng số trong khi TIMESTAMP bị ảnh hưởng bởi time_zone cài đặt.

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

Nói 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 một 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 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ề DATETIME đang được sử dụng khi TIMESTAMP nên được sử dụng là trong Facebook, nơi mà các máy chủ của họ không bao giờ chắc chắn về những gì thời gian xảy ra trên các múi giờ. Một khi tôi đã có một cuộc trò chuyện trong đó thời gian nói rằng tôi đã trả lời tin nhắn trước khi tin nhắn đã được gửi đi. (Điều này, tất nhiên, cũng có thể đã được gây ra bởi 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 được đồng bộ hóa.)


169
2018-01-14 14:26



Tôi không nghĩ đây là một cách suy nghĩ tốt. Tôi chỉ lưu trữ và xử lý tất cả các ngày trong UTC và đảm bảo rằng front-end hiển thị nó theo múi giờ nhất định. Cách tiếp cận này rất đơn giản và có thể dự đoán được. - Kos
@Kos: không lưu trữ và xử lý tất cả các ngày trong UTC chính xác những gì TIMESTAMP đang thực hiện trong nội bộ? (Sau đó chuyển đổi nó để hiển thị múi giờ địa phương của bạn?) - carbocation
của tôi múi giờ địa phương? DB của bạn sẽ biết múi giờ của tôi như thế nào? ;-) Thường có một số xử lý giữa cơ sở dữ liệu và giao diện người dùng. Tôi làm nội địa hóa chỉ sau khi xử lý toàn bộ. - Kos
@ Koz: cơ sở dữ liệu của tôi không biết múi giờ cơ sở dữ liệu của bạn:! Nhưng nó không biết dấu thời gian. Cơ sở dữ liệu của bạn biết cài đặt múi giờ của chính nó và áp dụng điều đó khi diễn giải / biểu thị dấu thời gian. 1:01 sáng ngày 11 tháng 12 năm 2013 tại Bắc Kinh Trung Quốc không phải lúc nào cũng đúng lúc 1:01 sáng ngày 11 tháng 12 năm 2013 tại Sydney Australia. Google: 'múi giờ' và 'kinh tuyến chính'. - ekerner
Sự khác biệt không chỉ là về múi giờ của các máy chủ khác của cụm. Cài đặt có liên quan là múi giờ được xác định (theo mặc định giống với máy chủ, nhưng mặc định của bạn có thể phụ thuộc vào trình điều khiển phía máy khách) trong kết nối từ bất kỳ máy khách MySQL nào. - dolmen


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 điểm cố định (nhiều hơn hoặc ít hơn) trong thời gian. 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.


109
2018-01-03 17:11



dấu thời gian - điểm cố định trong thời gian, Thời gian quốc tế theo giờ phối hợp - liên quan đến một quan điểm, với tham chiếu thời gian (giờ địa phương ej), có thể là .. Giờ địa phương phối hợp? - yucer


TIMESTAMP là 4 byte Vs 8 byte cho DATETIME.

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

Nhưng như scronide cho biết nó có một giới hạn thấp hơn của năm 1970. Nó là tuyệt vời cho bất cứ điều gì có thể xảy ra trong tương lai mặc dù;)


86
2018-01-04 09:00



Tương lai kết thúc lúc 2038-01-19 03:14:07 UTC. - MattBianco
Thật là ngu xuẩn. Tôi nghĩ loại TIMESTAMP sẽ là "sẵn sàng trong tương lai" vì nó tương đối mới. Bạn không thể bận tâm chuyển đổi datetime thành UTC và quay lại mỗi khi bạn làm việc với các múi giờ khác nhau. Họ nên đã thực hiện TIMESTAMP lớn hơn .. ít nhất 1 byte lớn hơn. nó sẽ thêm 68 * 255 = 17340 năm nữa ... mặc dù nó sẽ không được căn chỉnh 32 bit. - NickSoft
Bạn có biết tại sao TIMESTAMP kết thúc vào năm 2038 không? Bởi vì nó là một số nguyên, và số nguyên có giới hạn là 2147483647. Tôi nghĩ rằng đây là lý do. Có thể nếu họ thay đổi loại của nó thành varchar và thay đổi cách thao tác nó, nó sẽ là "sẵn sàng trong tương lai". - vinsa
@ vinsa, tôi không nghĩ rằng nó sẽ là tương lai sẵn sàng sau đó. Vẫn còn nhớ lỗi Y2K? 2038 đang đến. - Pacerier
Đến năm 2038, MySQL (nếu nó vẫn tồn tại) sẽ chỉ cập nhật trường TIMESTAMP để sử dụng nhiều hơn 4 byte và cho phép phạm vi rộng hơn - the_nuts


  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 tháng và thời gian. MySQL truy xuất và hiển thị giá trị DATETIME ở định dạng HH: MM: SS 'HHYYY-MM-DD. Phạm vi được hỗ trợ là '1000-01-01 00:00:00' đến '9999-12-31 23:59:59 ′.

Loại 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.

  1. DATETIME là hằng số trong khi TIMESTAMP được thực hiện bởi thiết lập time_zone.

80
2017-12-21 11:12



Bạn cần phải làm rõ # 4: Dấu thời gian như được lưu trữ là hằng số và không tương đối (hoàn toàn bất khả tri) với múi giờ, trong khi đầu ra được hiển thị khi truy xuất bị ảnh hưởng bởi múi giờ của phiên yêu cầu. DATETIME luôn luôn liên quan đến múi giờ được ghi lại và phải luôn được xem xét trong bối cảnh đó, một trách nhiệm hiện tại rơi vào ứng dụng. - Christopher McGowan
Câu trả lời chính xác. Để thêm vào câu trả lời này, nếu chúng tôi cố gắng lưu trữ các giá trị vượt quá '2038-01-09 03:14:07', chúng tôi sẽ gặp lỗi hoặc được lưu trữ dưới dạng '0000-00-00 00:00:00'. Tôi đã nhận được lỗi này cho cơ sở dữ liệu của tôi vì nó có giá trị timeshifted (cho mục đích mã hóa). - Earnest_learner


Tôi khuyên bạn nên sử dụng cũng không trường DATETIME hoặc TIMESTAMP. Nếu bạn muốn đại diện cho một ngày cụ thể như toàn bộ (như ngày sinh), thì hãy sử dụng loại DATE, nhưng nếu bạn cụ thể hơn, bạn có thể quan tâm đến việc ghi lại khoảnh khắc thực tế thay vì một đơn vị thời gian (ngày, tuần, tháng, năm). Thay vì sử dụng DATETIME hoặc TIMESTAMP, sử dụng BIGINT và chỉ lưu trữ số mili giây kể từ kỷ nguyên (System.currentTimeMillis () 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 khóa nhà cung cấp. Khá nhiều cơ sở dữ liệu hỗ trợ các số nguyên theo kiểu tương đối tương tự. 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à Oracle định nghĩa chúng như thế nào không? Ngay cả trong các phiên bản khác nhau của MySQL, TIMESTAMPS có một mức độ chính xác khác nhau. Mới chỉ 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ố nhận xét sâu sắc ở đây về những gì xảy ra với múi giờ với các loại dữ liệu khác nhau. Nhưng liệu đây có phải là kiến ​​thức chung, và liệu các đồng nghiệp của bạn có dành thời gian để học nó không? Mặt khác, khá khó để thay đổi BigINT thành java.util.Date. Sử dụng BIGINT gây ra rất nhiều vấn đề với múi giờ bị rơi bên lề đườ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 phạm vi ngày trong tương lai (TIMESTAMP chỉ đến 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, nó không quan trọng đối với các công cụ của bên thứ 3 (ví dụ: EclipseLink) để giao tiếp với cơ sở dữ liệu. Không phải mọi công cụ của bên thứ ba sẽ có cùng một sự hiểu biết về một "datetime" như MySQL. Bạn muốn thử và tìm ra trong Hibernate cho dù bạn nên sử dụng một đối tượng java.sql.TimeStamp hoặc java.util.Date nếu bạn đang sử dụng các kiểu 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 sử dụng với các công cụ của bên thứ ba tầm thường.

Vấn đề này liên quan chặt chẽ đến cách bạn nên lưu trữ một giá trị tiền (tức là $ 1,99) trong một cơ sở dữ liệu. Bạn có nên sử dụng một số thập phân, hoặc loại tiền của cơ sở dữ liệu, hoặc tệ nhất của tất cả một đôi? Tất cả 3 trong số các tùy chọn này là khủng khiếp, vì nhiều lý do tương tự được liệt kê ở trên. Giải pháp là lưu trữ giá trị tiền bằng xu bằng BIGINT, sau đó chuyển đổi xu thành đô 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 để giải thích dữ liệu đó. Tất cả các loại dữ liệu ưa thích mà bạn thấy trong cơ sở dữ liệu (đặc biệt là Oracle) thêm ít, và bắt đầu bạn xuống con đường để khóa nhà cung cấp.


75
2018-06-11 23:02



Tôi thích giải pháp này. TIMESTAMP hết hạn vào năm 2038 là một vấn đề lớn. Điều đó không thực sự quá xa! - Charlie Dalsass
@ CharlieDalsass Bạn có nghĩ rằng phần mềm hiện tại sẽ ở đó vào thời điểm đó :-P - Habeeb Perwad
Tôi đang ở sự cố với TIMESTAMP. Lựa chọn BIGINT này có vẻ tốt hơn. - KcFnMi
Nó làm cho nó khó khăn để truy vấn dữ liệu theo ngày nếu nó được lưu trữ như một số mili giây - Ali Saeed
Đây thực sự là giải pháp tốt nhất nếu bạn quan tâm đến tính di động và xử lý người dùng trong nhiều múi giờ hoặc cơ sở dữ liệu ở múi giờ khác với người dùng. TIMESTAMP có thể là con đường để đi nếu nó không có lỗi thiết kế. Quá xấu mà các giải pháp bị hỏng có nhiều phiếu bầu hơn vì chúng được đăng sớm (năm!). - German


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

Vì vậy, đối với các giá trị đại diện cho thời gian của người dùng như một cuộc hẹn hoặc một lịch biểu, ngày giờ là tốt hơn. Nó cho phép người dùng kiểm soát ngày và thời gian 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 theo các thay đổi về cách tính thời gian tiết kiệm ánh sáng ban ngày (có thay đổi).

Mặt khác, đối với các giá trị đại diện cho 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ởi việc 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ủ trong 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.


37
2017-10-26 21:07





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 front-end gần đây nào (Angular 1/2, react, Vue, ...) có thể dễ dàng và tự động chuyển đổi datetime UTC của bạn thành giờ địa phương.

Ngoài ra:

(Trừ khi bạn có khả năng thay đổi múi giờ của các 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


31
2018-02-17 22:36



Dữ liệu của bạn không được đính kèm với cài đặt múi giờ của máy chủ của bạn. Có lẽ, nó làm việc cho bạn nếu bạn có hộp MySql đơn dưới bàn của bạn - Jin
@Jin UTC nghĩa là không có múi giờ như TIMESTAMP. Nếu tất cả các máy chủ của bạn đang ở UTC thì không có vấn đề gì. Có lẽ nó không làm việc cho bạn nếu bạn có cấu hình của năm 2000. - Sebastien Horin
TIMESTAMP có thể được nâng cấp lên giá trị 64 bit trong tương lai. Thế thì không còn vấn đề gì nữa. - twicejr
Tải toàn bộ thư viện của bên thứ ba để nắm bắt một cái gì đó như thế này có thể không được tuyệt vời cho hiệu suất, hoặc, có thể nó? Cho rằng đó là phía máy khách và không ảnh hưởng đến cơ sở dữ liệu của bạn ... Tuy nhiên, bất cứ điều gì bạn làm front-end S require yêu cầu kiểm tra serveride. Vì vậy, suy nghĩ của hoàn thành hình ảnh, nó thực sự giúp đỡ với vấn đề tốc độ? - Những điểm chuẩn đó hơi lạ một chút, tôi cảm thấy. Sử dụng một chuỗi trong một truy vấn để so sánh các lĩnh vực dấu thời gian cũng cảm thấy khá kỳ quặc. Điều đó cũng phải làm hại hiệu suất, phải không? - NoobishPro
@Babydead rõ ràng bạn sẽ không tải một thư viện chỉ để chuyển đổi một ngày nhưng sử dụng khung công tác kết thúc trước là một thực tiễn tốt cho một mã hiện đại và sạch sẽ - Sebastien Horin