Tác động của hệ thống như giỏ mua hàng là khách hàng (người mua) nào nằm trong một múi giờ và (người bán) ở múi giờ khác và ngày được thay đổi ở một đầu. vì vậy dữ liệu báo cáo cho một khách hàng đã mua khác với khách hàng khác?Nên DateTime được lưu trữ trong UTC hoặc giờ địa phương (của máy chủ) trong một trang web có thể truy cập trên toàn thế giới
Nếu nó đại diện cho một thời điểm, bạn chắc chắn nên sử dụng UTC. Điều đó nghe giống như lựa chọn đúng trong trường hợp cụ thể này.
Trong số các trường hợp khác, bạn muốn lưu trữ giờ địa phương - ví dụ: để báo thức sẽ tắt lúc 8 giờ sáng theo giờ địa phương, bất kể múi giờ người dùng đang ở. Điều này thường hữu ích cho lịch ứng dụng ... và bạn không lưu trữ một điểm duy nhất trong thời gian ở đây.
Ví dụ cụ thể về lý do tại sao giá trị lưu trữ điểm trong UTC là thời gian cục bộ có thể không rõ ràng do chuyển tiếp tiết kiệm ánh sáng ban ngày - nếu đồng hồ quay lại từ 2 giờ sáng đến 1 giờ sáng, sẽ có giờ địa phương là 1: 30 giờ sáng hai lần. Trong UTC, không có sự mơ hồ như vậy.
UTC mãi mãi! Nghiêm túc, nó có nghĩa là bạn không cần phải gây rối với điều chỉnh tiết kiệm ánh sáng ban ngày (hoặc địa phương) trong mô hình của bạn, chỉ trong quan điểm.
"Pro" lớn nhất của việc sử dụng UTC là nếu bạn chọn để đi với nó thì bạn luôn có thể chắc chắn ngày được lưu trữ theo cách đó và không bao giờ phải nghi ngờ chính mình. Điều này tiết kiệm rất nhiều rắc rối.
tôi nghĩ, lưu trữ không phải là vấn đề lớn nhất, quan trọng nhất là khi đặt cho một số ứng dụng như WEBSITE, API ... v.v, bạn phải gửi dưới dạng UTC + 0, có thể loại dài hơn?
UTC. Tôi biết một người dùng trong diễn đàn khác đã lưu trữ thời gian cục bộ từ máy tính người dùng cuối và một số người dùng đã quyết định rằng họ không cần tự động điều chỉnh cho DST. Bây giờ họ rất buồn.