Đối với ví dụ cụ thể mà bạn đã sử dụng cho câu hỏi của mình (năm 1200), về mặt kỹ thuật, mọi thứ sẽ hoạt động.
Tuy nhiên, nói chung, dấu thời gian là không thể sử dụng cho mục đích này. Đầu tiên, giới hạn phạm vi là tùy ý:trong MySQL là ngày 1 tháng 1 năm 1000. Nếu bạn đang làm việc với những thứ thuộc thế kỷ 12-13, mọi thứ vẫn ổn ... nhưng nếu tại một thời điểm nào đó bạn cần thêm một cái gì đó cũ hơn (thế kỷ 10 hoặc sớm hơn), ngày sẽ bị hỏng một cách đáng tiếc và việc khắc phục sự cố sẽ yêu cầu định dạng lại tất cả các ngày lịch sử của bạn thành một cái gì đó đầy đủ hơn.
Dấu thời gian thường được biểu diễn dưới dạng số nguyên thô, với "khoảng đánh dấu" và "điểm kỷ nguyên" cho trước, vì vậy con số thực sự là số dấu tích đã trôi qua kể từ kỷ nguyên đến ngày được đại diện (hoặc ngược lại đối với ngày âm). Điều này có nghĩa là, như với bất kỳ kiểu dữ liệu số nguyên cố định nào, tập hợp các giá trị có thể biểu diễn là hữu hạn. Hầu hết các định dạng dấu thời gian mà tôi biết về phạm vi hy sinh nghiêng về độ chính xác, chủ yếu là bởi vì các ứng dụng cần thực hiện số học thời gian thường cần làm như vậy với độ chính xác khá; trong khi các ứng dụng cần làm việc với ngày lịch sử rất hiếm khi cần thực hiện số học nghiêm túc.
Nói cách khác, dấu thời gian có nghĩa là chính xác đại diện của ngày tháng. Giai đoạn sơ khai thứ hai (hoặc thậm chí phần giây) không có ý nghĩa gì đối với các niên đại lịch sử:bạn có thể cho tôi biết, tính đến phần nghìn giây, khi Henry thứ 8 đăng quang làm Vua nước Anh?
Trong trường hợp của MySQL, định dạng vốn dĩ được định nghĩa là "năm 4 chữ số", vì vậy bất kỳ tối ưu hóa liên quan nào có thể dựa trên giả định rằng năm sẽ có 4 chữ số hoặc toàn bộ chuỗi sẽ có chính xác 10 ký tự ("yyyy- mm-dd "), v.v. Chỉ là một vấn đề may mắn là ngày bạn đề cập trên tiêu đề của bạn vẫn phù hợp, nhưng thậm chí dựa vào đó vẫn rất nguy hiểm:ngoài những gì bản thân DB có thể lưu trữ, bạn cần phải biết những gì phần còn lại của ngăn xếp máy chủ của bạn có thể thao tác. Ví dụ:nếu bạn đang sử dụng PHP để tương tác với cơ sở dữ liệu của mình, việc cố gắng xử lý các ngày lịch sử rất có thể xảy ra sự cố vào lúc này hay lúc khác (trên môi trường 32 bit, phạm vi cho dấu thời gian kiểu UNIX là từ ngày 13 tháng 12 năm 1901 đến hết Ngày 19 tháng 1 năm 2038).
Tóm lại:MySQL sẽ lưu trữ đúng bất kỳ ngày nào có năm 4 chữ số; nhưng nói chung việc sử dụng dấu thời gian cho các ngày lịch sử gần như được đảm bảo sẽ kích hoạt các vấn đề và đau đầu thường xuyên hơn không. Tôi đặc biệt khuyên không nên sử dụng như vậy.
Hy vọng điều này sẽ hữu ích.
Chỉnh sửa / bổ sung:
Tôi không nghĩ rằng bất kỳ DB nào cũng hỗ trợ quá nhiều cho loại ngày này:các ứng dụng sử dụng nó thường xuyên nhất có đủ với biểu diễn chuỗi- / văn bản-. Trên thực tế, đối với các ngày từ năm 1 trở về sau, biểu diễn dạng văn bản thậm chí sẽ mang lại so sánh / sắp xếp chính xác (miễn là ngày được biểu thị theo thứ tự độ lớn:thứ tự y, m, d). Các phép so sánh sẽ bị phá vỡ, tuy nhiên, nếu cũng liên quan đến ngày "âm" (chúng sẽ vẫn so sánh sớm hơn bất kỳ ngày dương nào, nhưng so sánh hai ngày âm sẽ mang lại kết quả đảo ngược).
Nếu bạn chỉ cần các ngày từ Năm 1 trở lên hoặc nếu bạn không cần phân loại, thì bạn có thể làm cho cuộc sống của mình dễ dàng hơn rất nhiều bằng cách sử dụng chuỗi ký tự.
Nếu không, cách tiếp cận tốt nhất là sử dụng một số loại số và xác định "khoảng thời gian đánh dấu" và "điểm kỷ nguyên" của riêng bạn. Khoảng thời gian tốt có thể là ngày (trừ khi bạn thực sự cần phân bổ trước thêm, nhưng thậm chí sau đó bạn có thể dựa vào số "thực" (dấu phẩy động) thay vì số nguyên); và thời điểm hợp lý có thể là ngày 1 tháng 1, ngày 1 tháng 1, vấn đề chính sẽ là chuyển các giá trị này thành biểu diễn văn bản của chúng và ngược lại. Bạn cần lưu ý những chi tiết sau:
- Năm nhuận có thêm một ngày.
- Quy tắc cho các năm nhuận là "bội số bất kỳ của 4" cho đến năm 1582, khi nó thay đổi từ lịch Julian sang lịch Gregory và trở thành "bội số của 4 trừ những năm nhuận là bội số của 100 trừ khi chúng cũng là bội số của 400".
- Ngày cuối cùng của lịch Julian là ngày 4 tháng 10 năm 1582. Ngày tiếp theo, ngày đầu tiên của lịch Gregorian, là ngày 15 tháng 10 năm 1582. Đã bỏ qua 10 ngày để lịch mới khớp lại với các mùa.
- Như đã nêu trong phần bình luận, hai quy tắc trên khác nhau tùy theo quốc gia:Các quốc gia của Giáo hoàng và một số quốc gia theo đạo Thiên chúa đã áp dụng lịch mới vào những ngày đã nêu, nhưng nhiều quốc gia khác mất nhiều thời gian hơn để làm như vậy (nước cuối cùng là Thổ Nhĩ Kỳ vào năm 1926) . Điều này có nghĩa là bất kỳ ngày tháng nào giữa con bò đực của Giáo hoàng vào năm 1582 và lần cuối cùng được thông qua vào năm 1926 sẽ không rõ ràng nếu không có bối cảnh địa lý và thậm chí còn phức tạp hơn để xử lý.
- Không có "năm 0":năm trước năm 1 là năm -1 hoặc năm 1 trước Công nguyên.
Tất cả điều này đòi hỏi các chức năng phân tích cú pháp và định dạng khá phức tạp, nhưng ngoài nhiều trường hợp phân tích, thực sự không có quá nhiều phức tạp (sẽ rất tẻ nhạt đối với mã, nhưng khá dễ hiểu). Việc sử dụng các số làm đại diện cơ bản đảm bảo sắp xếp / so sánh chính xác cho bất kỳ cặp giá trị nào.
Biết được điều này, bây giờ bạn có thể lựa chọn cách tiếp cận phù hợp hơn với nhu cầu của mình.
