Số giây đã trôi qua kể từ Epoch

• Số giây kể từ Epoch

  • Thời gian POSIX, hay thời gian Unix, thường được cho là số giây kể từ 00:00:00 ngày 1 tháng 1 năm 1970. Tuy nhiên, điều này không chính xác. Ví dụ, thời gian POSIX của 2024-12-25 18:54:53 UTC là 1735152686, thấp hơn 29 giây so với số giây thực tế đã trôi qua là 1735152715.

  • Thời gian POSIX được suy ra từ Giờ Phối hợp Quốc tế (UTC) trong IEEE 1003.1. Tiêu chuẩn này giả định mỗi ngày dài đúng 86.400 giây. Nhưng trên thực tế, độ dài của một ngày không phải lúc nào cũng là 86.400 giây và thay đổi theo thời gian. Để điều chỉnh điều này, các nhà thiên văn học định kỳ công bố giây nhuận cho UTC.

• Khảo cổ học

  • Phụ lục B của IEEE 1003 có một phần thảo luận thú vị về giây nhuận. Vào thời điểm tiêu chuẩn được ban hành, đã có 14 giây nhuận được thêm vào kể từ ngày 1 tháng 1 năm 1970. Các giây nhuận này bị bỏ qua để việc tính chênh lệch thời gian trở nên dễ dàng hơn.

  • Hầu hết các hệ thống xem thời gian là một giá trị tăng liên tục. Nhưng đa số hệ thống không theo dõi giây nhuận và cũng không được đồng bộ với tham chiếu thời gian chuẩn. Vì vậy, yêu cầu rằng số giây kể từ Epoch phải biểu thị chính xác số giây giữa thời điểm được tham chiếu và Epoch là không phù hợp.

  • Cách diễn giải nhất quán về số giây kể từ Epoch có thể quan trọng với một số loại ứng dụng phân tán. Sự tích lũy của giây nhuận là không thể dự đoán, và số giây nhuận kể từ Epoch có khả năng sẽ tiếp tục tăng.

• Nên làm gì thay thế

  • Để tính khoảng thời gian giữa hai sự kiện trên một máy tính, nên dùng CLOCK_MONOTONIC. Nếu không cần trao đổi thời gian POSIX với các hệ thống khác, có thể dùng TAI, GPS hoặc LORAN.

  • Nếu cần căn chỉnh tương đối với hệ thống dấu thời gian POSIX, có thể phân tán giây nhuận trên một khoảng thời gian dài hơn. Các thư viện như qntm của t-a-i hỗ trợ chuyển đổi giữa POSIX và TAI.

  • Hiện đang có các nỗ lực nhằm loại bỏ giây nhuận, với hy vọng hoàn tất vào năm 2035. Điều này sẽ đòi hỏi thêm công sức để xây dựng bảng chuyển đổi cho mọi thứ đang dựa trên giả định “mỗi ngày có 86.400 giây”, nhưng sẽ giúp việc hỏi có bao nhiêu giây giữa hai thời điểm trở nên đơn giản hơn. Ít nhất là đối với các thời điểm sau năm 2035.

[GN⁺]

Ý kiến trên Hacker News

• Đã đọc cuốn sách SF "A Deepness in the Sky". Thấy phần nhắc đến số giây kể từ epoch trong sách rất thú vị

  • Cách đo thời gian của Qeng Ho khá phức tạp, bắt đầu đếm giây từ khoảnh khắc con người lần đầu đặt chân lên Mặt Trăng
  • Thời điểm bắt đầu thực ra nằm sau khoảng 15 triệu giây, và đó là giây 0 của hệ điều hành máy tính đời đầu

• Đang có những nỗ lực nhằm loại bỏ leap second, và hy vọng sẽ hoàn tất vào năm 2035

  • Mục đích của UTC là xấp xỉ thời gian Mặt Trời trung bình bằng cách lệch một số nguyên giây so với TAI
  • Nếu không muốn bám theo MST thì phải chuyển sang TAI, và nếu UTC lệch khỏi MST thì các leap second mang tính lịch sử sẽ mất ý nghĩa

• "UTC epoch" hiện đại là ngày 1 tháng 1 năm 1972

  • Cuối năm 1971 đã có một bước nhảy không đều 0.107758 giây TAI, sau đó tốc độ tick của UTC được đổi để khớp chính xác với TAI
  • Unix time của năm 1970 và 1971 thực ra không khớp với thời gian UTC thực tế của giai đoạn đó

• Mỗi lần đọc về đo thời gian lại học thêm được điều mới

  • Từng nghĩ Unix time là cách theo dõi thời gian đơn giản nhất
  • Cũng từng nghĩ nó không áp dụng leap second, nhưng có lẽ đã không suy nghĩ đủ kỹ

• Gần đây đã làm việc với VAX, hoặc với mã chạy trên OpenVMS, và lần đầu thấy epoch là ngày 17 tháng 11 năm 1858

  • Trong mã, nó đã được trừu tượng hóa thành Unix epoch

• Có những thời điểm không thể biểu diễn bằng dấu thời gian POSIX, và cũng có những dấu thời gian POSIX không khớp với thời gian thực

• Nghĩ rằng bài viết này đã phá hỏng Giáng sinh

  • Giây nên là số giây kể từ epoch, và không cần quan tâm việc nó lệch khỏi ngày Mặt Trời
  • Bộ chuyển đổi giây-epoch nên chịu trách nhiệm xử lý phần hiệu chỉnh

• Khi lưu ngày tháng vào cơ sở dữ liệu, luôn lưu dưới dạng thời gian Unix epoch, còn thông tin múi giờ thì lưu riêng

  • Đang cân nhắc liệu lưu dấu thời gian theo định dạng TAI rồi chuyển sang UTC khi cần có tốt hơn không
  • Múi giờ là một khái niệm do con người tạo ra và sẽ được điều chỉnh theo thời gian
  • Nên lấy thời gian tuyệt đối làm chuẩn, rồi chuyển sang định dạng giờ địa phương khi cần

• Khoảng 10 năm trước tại một hội nghị, đã nghe nói Google không dùng leap second mà phân tán nó vào các giây thông thường

  • Google sửa các máy chủ NTP để phân tán leap second

• Tò mò liệu có cách đo thời gian nào vừa được đồng bộ vừa tăng đơn điệu hay không