Cơ sở Dữ liệu Múi Giờ IANA Thực Sự Là Gì
Nếu bạn đã từng làm việc với ngày và giờ trong phần mềm, bạn đã từng dựa vào Cơ sở Dữ liệu Múi Giờ IANA dù bạn có biết hay không. Nó có nhiều tên gọi — cơ sở dữ liệu tz, tzdata, cơ sở dữ liệu Olson, hoặc zoneinfo — nhưng tất cả đều chỉ cùng một thứ: một danh mục cộng tác, miễn phí về các múi giờ trên thế giới và các quy tắc chi phối chúng.
Từ "danh mục" chưa nói lên hết giá trị. Cơ sở dữ liệu không chỉ đơn thuần liệt kê khu vực nào nằm ở độ lệch UTC nào. Nó ghi lại toàn bộ lịch sử về cách tính giờ dân sự cho từng khu vực — mọi thay đổi độ lệch, mọi chuyển đổi giờ mùa hè, mọi điều chỉnh đồng hồ thời chiến, và mọi quy tắc tương lai đã được lên lịch — trong nhiều trường hợp, quay ngược về giữa thế kỷ 19 khi giờ địa phương trung bình nhường chỗ cho các múi giờ chuẩn hóa. Khi ứng dụng lịch của bạn hiển thị chính xác rằng một cuộc họp năm 1985 diễn ra lệch một giờ so với cùng một giờ trên đồng hồ ngày hôm nay, đó là công việc của cơ sở dữ liệu tz.
Nó dựa trên văn bản, con người có thể đọc được và nhỏ gọn. Dạng nhị phân đã biên dịch được cài đặt trên máy tính của bạn chỉ nặng vài megabyte. Tuy nhiên, nó mã hóa một trong những bộ dữ liệu phức tạp một cách âm thầm nhất trong điện toán.
Lịch Sử Ngắn Gọn
Dự án bắt đầu vào những năm 1980 dưới sự dẫn dắt của Arthur David Olson, người đã tập hợp phiên bản đầu tiên và lưu trữ nó trên các máy chủ tại Viện Y tế Quốc gia Hoa Kỳ. Trong nhiều thập kỷ, nó được duy trì phần lớn thông qua nỗ lực tình nguyện phối hợp qua một danh sách gửi thư công khai, đó là lý do tại sao tên cũ "cơ sở dữ liệu Olson" vẫn xuất hiện trong tài liệu.
Paul Eggert đã tiếp quản vai trò biên tập viên chính và vẫn là người điều phối lâu năm của dự án. Việc biên soạn tài liệu theory.html đi kèm và lịch sử commit tỉ mỉ của ông đã biến cơ sở dữ liệu này thành một tài liệu tham khảo lịch sử cũng như kỹ thuật.
Năm 2011, sau một tranh chấp pháp lý ngắn nhưng đáng báo động về dữ liệu lịch sử, quyền quản lý được chuyển giao cho Cơ quan Cấp phát Số Hiệu Internet (IANA), cùng một tổ chức điều phối các tài nguyên cốt lõi khác của Internet. IANA hiện phát hành các bản phát hành chính thức, đó là lý do tại sao "cơ sở dữ liệu múi giờ IANA" đã trở thành tên chính thống. Công việc vẫn do cùng một cộng đồng những người đóng góp thực hiện; IANA cung cấp một ngôi nhà thể chế và một điểm phân phối ổn định.
Quy Tắc Đặt Tên: KhuVực/ĐịaĐiểm
Một trong những đặc điểm nổi bật nhất của cơ sở dữ liệu là cách nó đặt tên cho các múi giờ. Thay vì tên quốc gia hoặc độ lệch thô, nó sử dụng định dạng KhuVực/ĐịaĐiểm, hầu như luôn gắn với một thành phố đại diện:
America/New_YorkEurope/LondonAsia/KolkataAustralia/Sydney
"KhuVực" thường là một lục địa hoặc đại dương (America, Europe, Asia, Pacific), và "ĐịaĐiểm" là một thành phố nổi tiếng trong múi giờ đó. Sự lựa chọn này trông có vẻ kỳ quặc cho đến khi bạn hiểu lý do đằng sau nó.
Các thành phố ổn định; các ranh giới chính trị và độ lệch thì không. Các quốc gia chia tách, sáp nhập, đổi tên và thay đổi đồng hồ của họ. Ngược lại, một thành phố là một điểm địa lý cố định với lịch sử tính giờ liên tục. Đặt tên một múi giờ là America/New_York thay vì "Giờ Miền Đông Hoa Kỳ" hoặc "UTC-5" có nghĩa là định danh vẫn có giá trị ngay cả khi các quy tắc gắn liền với nó phát triển.
Cơ sở dữ liệu cũng cố tình tránh tên quốc gia để tránh các tranh chấp chính trị và vì một quốc gia thường chứa nhiều múi giờ — Hoa Kỳ có hơn một chục múi giờ. Nó chọn thành phố đông dân nhất hoặc có ý nghĩa lịch sử nhất trong mỗi múi giờ riêng biệt làm nhãn trung lập. Khi hai khu vực có chung lịch sử đồng hồ giống hệt nhau kể từ năm 1970, chúng dùng chung một múi giờ; ngay khi lịch sử của chúng khác biệt, chúng có các mục riêng.
Tại Sao Độ Lệch Thô Là Không Đủ
Một bản năng phổ biến của người mới bắt đầu là lưu trữ thời gian dưới dạng "UTC+5:30" và coi như xong. Điều này hiệu quả cho một thời điểm duy nhất, nhưng nó thất bại ngay khi bạn cần suy luận về các sự kiện trong tương lai hoặc định kỳ, bởi vì độ lệch không phải là thuộc tính tĩnh của một địa điểm. Chúng là kết quả đầu ra của các quy tắc mà chính phủ thay đổi liên tục và thường xuyên đột ngột.
Hãy xem xét một vài ví dụ thực tế mà cơ sở dữ liệu đã phải tiếp nhận:
- Samoa đã bỏ qua hoàn toàn ngày 30 tháng 12 năm 2011. Để đồng bộ ngày làm việc của mình với Úc và New Zealand thay vì Hoa Kỳ, Samoa đã nhảy qua Đường Ngày Quốc tế, chuyển từ UTC-11 sang UTC+13. Đối với bất kỳ ai trên quần đảo, thứ Sáu đó đơn giản là không tồn tại.
- Các quốc gia bãi bỏ, áp dụng hoặc điều chỉnh lịch giờ mùa hè mà ít thông báo trước. Liên minh Châu Âu đã tranh luận về việc kết thúc DST; một số quốc gia và tiểu bang Hoa Kỳ đã thay đổi quy tắc DST của họ trong những thập kỷ gần đây. Thổ Nhĩ Kỳ, Nga và các nước khác đã thay đổi hoàn toàn độ lệch chuẩn của họ.
- Ngày bắt đầu và kết thúc DST thay đổi. Hoa Kỳ đã thay đổi ranh giới DST của mình vào năm 2007. Bất kỳ hệ thống nào mã hóa cứng quy tắc cũ đều âm thầm tạo ra thời gian sai trong nhiều tuần mỗi năm.
Nếu bạn chỉ lưu trữ một độ lệch, bạn không thể trả lời câu hỏi "giờ địa phương sẽ là bao nhiêu ở Santiago vào ngày 15 tháng 11 năm sau?" — bởi vì câu trả lời phụ thuộc vào các quy tắc thậm chí có thể chưa được hoàn thiện. Lưu trữ định danh múi giờ (America/Santiago) cùng với cơ sở dữ liệu cho phép phần mềm tính toán độ lệch chính xác cho bất kỳ thời điểm nào, quá khứ hoặc tương lai, và tự động tính toán lại khi các quy tắc thay đổi.
Đây là giá trị cốt lõi: cơ sở dữ liệu tz tách biệt danh tính của một địa điểm khỏi các quy tắc luôn thay đổi xác định đồng hồ của nó.
Cách Nó Được Duy Trì
Việc bảo trì diễn ra một cách công khai. Các thay đổi được đề xuất — một quy tắc DST mới, một ngày lịch sử được hiệu chỉnh, một thông báo của chính phủ — được thảo luận trên danh sách gửi thư tz công khai, nơi những người đóng góp trích dẫn các công báo chính thức, báo cáo tin tức và sắc lệnh của chính phủ làm bằng chứng. Tính chính xác được coi trọng; các thay đổi đối với dữ liệu lịch sử nói riêng được xem xét kỹ lưỡng dựa trên các nguồn chính.
Các bản phát hành được đánh phiên bản bằng một năm và một chữ cái: 2024a, 2024b, 2024c, v.v. Số là năm; chữ cái tăng dần theo mỗi lần phát hành trong năm đó. Bởi vì các chính phủ công bố thay đổi đồng hồ theo lịch trình khó đoán của riêng họ, không có nhịp độ phát hành cố định — một năm yên tĩnh có thể có hai bản phát hành, trong khi một năm có nhiều biến động chính trị có thể có nhiều bản. Các hệ thống được mong đợi sẽ cập nhật kịp thời, vì một cơ sở dữ liệu lỗi thời có thể đồng nghĩa với việc hiển thị sai thời gian sau khi một quy tắc thay đổi có hiệu lực.
Ai Phụ Thuộc Vào Nó
Hầu như mọi thứ.
- Hệ điều hành. Các bản phân phối Linux cài đặt
tzdatanhư một gói cốt lõi. macOS lấy dữ liệu múi giờ từ cùng một nguồn. Windows sử dụng các múi giờ dựa trên registry riêng vì lý do kế thừa nhưng hiển thị các múi giờ IANA thông qua thư viện ICU và các API hiện đại. - Ngôn ngữ lập trình. Hầu như mọi thư viện ngày/giờ trưởng thành đều đọc từ hoặc đóng gói cơ sở dữ liệu tz:
zoneinfocủa Python,java.timecủa Java, dự án ICU, PostgreSQL, các công cụ JavaScript thông qua ICU, Ruby, PHP, và nhiều ngôn ngữ khác. - Ứng dụng. Lịch, hệ thống đặt chỗ, nền tảng giao dịch tài chính, công cụ phân tích nhật ký và dịch vụ lập lịch đều dựa vào nó, thường là không để các nhà phát triển phải suy nghĩ về nó.
Sự phổ biến này chính xác là lý do tại sao cơ sở dữ liệu lại quan trọng đến vậy. Một nguồn sự thật duy nhất, được chia sẻ, được duy trì cẩn thận có nghĩa là một cuộc họp được lên lịch trong một hệ thống sẽ hiển thị chính xác trong một hệ thống khác, trên các hệ điều hành và ngôn ngữ, trong nhiều thập kỷ trong quá khứ hoặc tương lai.
Nếu bạn muốn khám phá các múi giờ, hãy duyệt danh sách đầy đủ các Múi giờ IANA hoặc xem cách chúng ánh xạ trên toàn cầu trong thư mục Tất cả múi giờ của chúng tôi.
Các Câu Hỏi Thường Gặp
Cơ sở dữ liệu tz có giống với tzdata, zoneinfo và cơ sở dữ liệu Olson không?
Có. Đây đều là các tên gọi cho cùng một dự án. "tzdata" thường đề cập đến các tệp dữ liệu được đóng gói cho một hệ điều hành, "zoneinfo" đề cập đến thư mục nhị phân đã biên dịch, và "cơ sở dữ liệu Olson" là tên lịch sử cũ hơn theo tên người sáng lập Arthur David Olson. Ngày nay, tên chính thức là Cơ sở Dữ liệu Múi Giờ IANA.
Cơ sở dữ liệu được cập nhật bao lâu một lần?
Không có lịch trình cố định. Các bản phát hành được kích hoạt bởi các sự kiện trong thế giới thực — một chính phủ thay đổi quy tắc DST hoặc độ lệch chuẩn, hoặc một sự hiệu chỉnh đối với dữ liệu lịch sử. Một số năm chỉ có một bản phát hành; những năm khác có nhiều bản. Mỗi bản được đặt tên như 2024a, 2024b, tăng dần chữ cái trong suốt năm.
Tại sao nó đặt tên múi giờ theo các thành phố như America/New_York?
Các thành phố cố định về mặt địa lý và có lịch sử tính giờ liên tục, trong khi các quốc gia, biên giới và độ lệch thay đổi theo thời gian. Sử dụng một thành phố đại diện mang lại cho mỗi múi giờ một định danh ổn định, trung lập về chính trị, vẫn có giá trị ngay cả khi các quy tắc DST hoặc độ lệch cơ bản thay đổi.
Tôi có thể chỉ lưu trữ độ lệch UTC thay vì tên múi giờ không?
Chỉ cho một thời điểm cố định duy nhất. Đối với các sự kiện trong tương lai hoặc định kỳ, bạn nên lưu trữ định danh múi giờ, bởi vì độ lệch thay đổi theo giờ mùa hè và các quyết định của chính phủ. Tên múi giờ cùng với cơ sở dữ liệu cho phép phần mềm tự động tính toán độ lệch chính xác cho bất kỳ ngày nào.
Ai điều hành dự án bây giờ?
Nó được xuất bản bởi IANA, tổ chức đã tiếp quản quyền quản lý vào năm 2011, và được điều phối bởi Paul Eggert với một cộng đồng những người đóng góp làm việc trên danh sách gửi thư tz công khai. Công việc kỹ thuật vẫn là một nỗ lực hợp tác, do tình nguyện viên thúc đẩy.