Không thêm giây nhuận vào cuối tháng 12 năm 2026

 (datacenter.iers.org)
1 điểm bởi GN⁺ 4 giờ trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Theo IERS Bulletin C 72, UTC vào cuối tháng 12 năm 2026 sẽ không được thêm giây nhuận, nên các hệ thống đo lường và phân phối thời gian không cần chuẩn bị xử lý chèn bổ sung
  • Chênh lệch giữa UTC và TAI sẽ được giữ ở mức UTC-TAI = -37 s từ 0:00 UTC ngày 1 tháng 1 năm 2017 cho đến khi có thông báo tiếp theo
  • Việc có áp dụng giây nhuận hay không được quyết định theo biến động của UT1-TAI, và các thời điểm có thể áp dụng là cuối tháng 6 hoặc cuối tháng 12
  • Bulletin C được công bố mỗi 6 tháng để thông báo bước thời gian UTC (time step), hoặc xác nhận không có bước thời gian vào ngày có thể áp dụng tiếp theo
  • Việc phân phối UTC vào cuối năm 2026 không cần giá trị hiệu chỉnh mới, và có thể tiếp tục sử dụng quan hệ UTC-TAI = -37 s hiện tại

Thông báo UTC trong IERS Bulletin C 72

  • IERS cho biết trong Bulletin C 72 phát hành tại Paris ngày 6 tháng 7 năm 2026 rằng sẽ không áp dụng giây nhuận vào cuối tháng 12 năm 2026
  • Thông báo này dành cho các tổ chức chịu trách nhiệm đo lường và phân phối thời gian
  • Có hai giá trị cốt lõi như sau
    • UTC-TAI = -37 s từ 0:00 UTC ngày 1 tháng 1 năm 2017 cho đến khi có thông báo tiếp theo
    • Không có bước thời gian mới cho UTC vào cuối tháng 12 năm 2026

Quyết định giây nhuận và chu kỳ thông báo

  • Giây nhuận có thể được đưa vào UTC tùy theo biến động của UT1-TAI
  • Các thời điểm có thể áp dụng là cuối tháng 6 hoặc cuối tháng 12 hằng năm
  • Bulletin C được phát hành mỗi 6 tháng
    • Nếu UTC có bước thời gian, bản tin sẽ công bố điều đó
    • Nếu không có bước thời gian vào ngày có thể áp dụng tiếp theo, bản tin sẽ xác nhận điều đó

Bài viết liên quan

1 bình luận

 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Tôi thắc mắc tính không thể dự đoán này phát sinh do đâu. Có vẻ như ta phải biết khá chính xác tốc độ tự quay và quỹ đạo của Trái Đất đến rất nhiều chữ số thập phân rồi chứ; có phải các yếu tố như hoạt động địa chất hay thời tiết tạo ra khác biệt trong tốc độ quay nên khó dự đoán không?

    • Nói ngắn gọn thì đúng vậy. Thời tiết, hoạt động địa chất, cùng với việc con người di chuyển nước như làm cạn tầng chứa nước, xây đập, cũng như sự tan chảy của sông băng và băng, đều gây ra những thay đổi khó dự đoán đối với chu kỳ quay và trục quay của Trái Đất
      Nếu tôi nhớ không nhầm thì các mô hình này là các đa thức lượng giác bậc thấp, nên ngay cả khi mô hình hóa hoàn hảo tính không thể dự đoán thì vẫn khó phân phối với độ chính xác rất cao do sai số cắt cụt, và chúng đã được nhúng sẵn vào những thứ như vệ tinh nên cũng không thể tùy ý làm phức tạp hơn
      Nhân tiện, tôi biết là giây nhuận sắp bị loại bỏ, và theo tôi biết thì sẽ dần ngừng áp dụng vào năm 2035. Tôi nhớ việc này bị trì hoãn vì Russia cần thời gian để cập nhật các vệ tinh GLONASS
    • Đúng vậy. Có các yếu tố đó và còn nhiều hơn nữa. Độ chính xác đo lường của chúng ta tốt hơn rất nhiều so với các tốc độ biến thiên bậc một và bậc hai thay đổi theo từng năm của độ dài ngày
      https://datacenter.iers.org/singlePlot.php?plotname=Bulletin... là biểu đồ liên quan nhất đến chuyện này, và các bước nhảy theo phương thẳng đứng biểu thị giây nhuận. IERS còn có các biểu đồ cho những khía cạnh khác của chuyển động quay, nhưng biểu đồ này dễ xem
    • Tôi vừa tra bài Wikipedia để xem chính xác giây nhuận cuối cùng được thêm vào khi nào, và câu trả lời cũng nằm ngay ở đó
      “Tốc độ quay của Trái Đất thay đổi để phản ứng với các sự kiện khí hậu và địa chất, vì vậy các giây nhuận UTC được đặt không đều và không thể dự đoán chính xác”
      https://en.wikipedia.org/wiki/Leap_second
    • Thực ra gần như ngược lại mới đúng. Chuyển động quay của Trái Đất có thể thay đổi vài giây theo từng năm, nhưng trên thang hàng trăm năm thì những dao động đó phần lớn triệt tiêu lẫn nhau
      Vì vậy tôi cho rằng việc cố thêm hoặc bớt giây nhuận không phải ý hay. Trên thực tế chỉ có các cơ quan vũ trụ mới quan tâm chuyện này, và họ có thể tự áp dụng giá trị hiệu chỉnh mình muốn mà không cần ảnh hưởng đến tất cả mọi người
      Tác động thực tế của độ trôi này với người bình thường có lẽ chỉ là GPS, nhưng GPS đã tự truyền độ lệch so với đồng hồ riêng của nó để thiết bị thu có thể hiệu chỉnh. Đồng hồ GPS khác cả UTC lẫn TAI
    • Xem https://en.wikipedia.org/wiki/Leap_second#:~:text=Other%20co...

  • Chẳng phải đây đúng hơn là phi tin tức sao? Tôi nhớ mang máng là do nó gây ra quá nhiều vấn đề cho các hệ thống tính toán hiện đại nên người ta đã dừng áp dụng giây nhuận cho đến khi có thông báo khác
    Hiện giờ chênh lệch là 37 giây, và chẳng ai cần lo Giáng sinh sẽ bị dời đến gần dịp Phục sinh cả. Tôi nghĩ đây là vấn đề có thể để lại cho các thế hệ tương lai giải quyết một cách có trách nhiệm hơn so với nhiều vấn đề khác
    Việc cứ 6 tháng lại ra thông báo chỉ là thủ tục để khớp với câu chữ của hiệp ước quốc tế ban đầu mà thôi

    • Vẫn chưa phải như vậy. Mới chỉ là đề xuất thôi, và khả năng cao là việc dừng chính thức sẽ khó xảy ra trước năm 2035
      Lý do một thời gian qua không có giây nhuận là vì độ trôi giữa TAI và UT1 đã chậm lại, và thực tế đang dịch chuyển rất chậm theo hướng ngược lại
    • Tôi thấy việc thời gian thông báo chỉ có 6 tháng là vô lý, và đó có thể chính là nguồn gốc của vấn đề
      Dù thời gian lệch khoảng ±60 giây thì cũng chẳng ai nhận ra, nên có vẻ dễ quản lý hơn nếu cứ khoảng 10 năm lại chèn một giây nhuận tùy ý và thông báo trước 10 năm để mọi người có thời gian dọn dẹp hệ thống. 6 tháng để cả thế giới phối hợp triển khai là lạc quan đến mức phi thực tế

  • Nếu giải thích như cho một đứa trẻ 5 tuổi, tôi muốn biết việc này ảnh hưởng thế nào đến UNIX timestamp. Đặc biệt là với những thứ đang ở chế độ bảo trì hoặc gần như không được quản lý
    Công việc của tôi không cần mức độ chính xác này, nhưng chắc chắn có những lĩnh vực cần

    • UNIX timestamp bỏ qua hoàn toàn giây nhuận và coi như chúng không tồn tại
      Vì thế khi một giây nhuận được chèn vào, có thể xuất hiện một giây vật lý không thể tham chiếu bằng UNIX timestamp; còn khi một giây nhuận bị xóa đi, có thể xuất hiện một UNIX timestamp cho một giây thực tế không hề tồn tại
    • Mỗi khi có thêm giây nhuận, Google sẽ cho đồng hồ máy chủ chạy chậm hơn hoặc nhanh hơn trong một khoảng thời gian dài hơn, thường là vài giờ, để từ từ đồng bộ lại với chiếc đồng hồ quả lắc hình cầu hoàn hảo bằng bạch kim nguyên chất nào đó của NIST: https://developers.google.com/time/smear
    • Kết quả của time() và clock_gettime(CLOCK_REALTIME) bị ảnh hưởng bởi giây nhuận
      Giây nhuận mới sẽ đến hệ thống qua NTP. Đáng tiếc là NTP chỉ phân phối một cờ báo hiệu rằng sẽ có giây nhuận chứ không phân phối chính độ lệch đó. Tuy nhiên, bản thân thời gian được phân phối đã bị ảnh hưởng bởi giây nhuận nên client NTP không nhất thiết phải biết điều đó
      Ngược lại, các phương thức đồng bộ thời gian khác như GPS và PTP dùng các thang thời gian không bị ảnh hưởng bởi giây nhuận và phân phối độ lệch UTC như thông tin bổ sung. Việc sửa đổi thời gian nhận được ở bước cuối là phần việc của client. Kernel có tham số clock_adjtime() cho giây nhuận
      Với một hệ thống thủ công có NTP client, thời gian sẽ được thay đổi trong lúc chạy để khớp với giây nhuận mới. Linux ưu tiên xử lý thời gian UTC nên thời gian này được lưu vào thiết bị RTC và được giữ lại sau khi khởi động lại
      CLOCK_TAI có vẻ như lẽ ra phải trả về thời gian TAI, nhưng trên các bản phân phối Linux desktop/server thông thường, nó còn bị đối xử hạng hai đến mức ngay cả độ lệch cũng không được thiết lập, nên trả về cùng thời gian với CLOCK_REALTIME
      Trong /etc có một tệp danh sách giây nhuận đi kèm trong một gói nào đó, và để cập nhật tệp này thì cần cập nhật hệ thống. Tôi không nghĩ phần mềm NTP truyền thống sẽ cập nhật động gói này. Dù vậy, cũng không có nhiều phần mềm dùng tệp này
      Nếu có một script dịch vụ init nào đó phân tích tệp này để thiết lập độ lệch UTC của kernel, thì CLOCK_TAI của hệ thống có thể chậm hơn phần còn lại của thế giới 1 giây cho đến khi được cập nhật. Nhưng theo tôi biết, điều đó không ảnh hưởng gì đến thời gian UTC của Linux

  • Cụm từ “gửi tới các cơ quan chịu trách nhiệm đo lường và phân phối thời gian” đúng là đỉnh cao chuyên môn

    • Còn hay hơn ở chỗ tên tổ chức đó là International Earth Rotation Service
    • Trong nhiều năm, chức danh lãnh đạo phụ trách các sản phẩm thời gian chính xác tại USNO là “Director of the Directorate of Time”
    • Nghe như một cụm từ bước ra từ tiểu thuyết của Douglas Adams
    • “Director Earth Orientation Center of IERS Observatoire de Paris, France”
      Ngay cả chức danh cũng mang cảm giác như sci-fi

  • Nếu độ lệch UTC-TAI vẫn giữ ở -37 giây thì điều đó cũng có nghĩa độ lệch UTC-GPS vẫn giữ ở -18 giây
    TAI và GPS có độ lệch cố định 19 giây giữa hai hệ

  • Tò mò không biết các hệ thống như Spanner sẽ ra sao trong trường hợp này
    Đây là chuyện đau đầu, hay thực ra chẳng đáng kể?

    • Là vấn đề lớn đấy. Cách xử lý phổ biến nhất được gọi là smearing, tức điều chỉnh độ dài của từng giây trong 24 giờ trước “giây nhuận”
      Với các hệ thống cần đảm bảo thứ tự nghiêm ngặt, cách này hoạt động được vì mỗi thiết bị vẫn duy trì đồng bộ với đồng hồ toàn cục, chỉ có độ dài chu kỳ đồng hồ là lệch đi một chút rất nhỏ. Hình như điều này có ngay trong bài báo Spanner gốc
      Một số hệ thống hiếm hơn dùng giây từ bộ dao động đơn điệu và bỏ qua giây quay của Trái Đất, nhưng nếu đến lúc nào đó vẫn phải chuyển đổi nó sang thời gian thực thì thảm họa sẽ tích lũy theo thời gian, nên nhìn chung đây không được xem là ý hay
    • Giây nhuận không được thêm theo lịch cố định như ngày nhuận mà thay đổi theo các phép đo vật lý của Trái Đất
      Vì vậy, có vẻ các hệ thống độ tin cậy cao với cơ chế quản lý thời gian toàn diện sẽ không bị xáo trộn quá nhiều bởi các quyết định như thế này

  • Nếu có Temporal API, liệu trình duyệt hay Node.js có thể xử lý thời gian đúng cách trong các phép tính quanh thời điểm đó không? Hay vẫn cần cập nhật để tránh làm hỏng phép tính?

    • Temporal API có vẻ dựa trên dấu thời gian Unix/POSIX, vốn bỏ qua giây nhuận. Trong thời gian Unix, một ngày luôn là 86400 “giây”
      Nhờ vậy có thể dễ dàng tính toán lịch UTC cho quá khứ và tương lai mà không cần cơ sở dữ liệu, và cũng không nhất thiết phải xử lý giây lẻ. Giây nhuận được hệ điều hành xử lý bằng cách lặp lại 1 giây, bỏ qua 1 giây, hoặc điều chỉnh độ dài giây trong một khoảng thời gian trước và sau giây nhuận
      Phần lớn API ngày giờ về cơ bản được thiết kế để hỗ trợ các phép tính lịch và giờ treo tường cho chức năng nghiệp vụ. Nếu cần giây SI cho mục đích khoa học, bạn phải dùng API và tính năng riêng có thể cung cấp và bảo đảm đúng ý nghĩa đó, thậm chí xuống tới cấp phần cứng
      Tương tự, nếu cần bộ hẹn giờ cho các chức năng phần mềm như sleep của thread, bạn phải dùng giao diện chuyên dụng như đồng hồ đơn điệu. Dù giây nhuận có dần biến mất thì tình hình này cũng không thay đổi nhiều. Có hay không có điều chỉnh giây nhuận, việc một thuật toán mutex dựa vào dấu thời gian Unix trước giờ đã sai và sau này vẫn sẽ sai

  • Nghe tôi này. Gắn động cơ phản lực vào xích đạo rồi xoay 180 độ là có thể lấy lại hoặc mất đi thời gian. Sau đó nối nó vào nút snooze của tôi

    • Chẳng phải sẽ dễ hơn nếu Superman bay vòng quanh Trái Đất thật nhanh thật nhiều lần sao? Như vậy khỏi phải lo bảo trì động cơ
    • Thực ra, nếu di chuyển một lượng nước cực lớn thì cũng có thể tạo ra ảnh hưởng đo được. Ví dụ như làm cạn tầng chứa nước Central Valley ở California
    • Vấn đề là xã hội tương lai sẽ thu hồi mấy cái động cơ đó để dùng cho tàu thám hiểm liên sao. Chuyện này từng được đề cập trong một bộ sách của Larry Niven
    • Có khi chỉ cần mọi người cùng nhảy lên đồng thời. Dù sao cũng chỉ cần 1–2 giây thôi mà?
    • Xem ra cách này hiệu quả thật, vì đã khá lâu rồi không cần chèn thêm giây nhuận

  • Có câu “chênh lệch giữa UTC và TAI là UTC-TAI = -37s từ 0:00 UTC ngày 1 tháng 1 năm 2017 cho đến khi có thông báo khác”
    Điều đó có nghĩa là đồng hồ nguyên tử chậm hơn 37 giây so với đồng hồ Mặt Trời sao? Tôi cũng không hiểu vì sao lại nhắc đến năm 2017

    • Thực ra gần như ngược lại
      Một ngày của UTC được định nghĩa là chính xác 86400 giây SI. Nhưng ngày Mặt Trời trung bình thực tế dài hơn vài mili giây. Do tính bất quy tắc trong chuyển động quay của Trái Đất, chênh lệch này không cố định, nhưng trung bình được dự đoán là sẽ tăng chậm theo thời gian. Vì giây SI được đếm bằng đồng hồ nguyên tử, UTC sẽ sang ngày mới sau mỗi 86400 giây nguyên tử
      Trong khi đó, đồng hồ Mặt Trời — sang ngày mới mỗi khi Mặt Trời trung bình đạt đến chính ngọ — sẽ sang ngày mới muộn hơn UTC vài mili giây. Mặt Trời thực ngoài đời di chuyển qua bầu trời với tốc độ thay đổi trong năm, nên phải dùng Mặt Trời trung bình
      Nói cách khác, mỗi khoảng thời gian mà đồng hồ Mặt Trời gọi là đúng 86400 giây thì theo đồng hồ nguyên tử lại dài hơn vài mili giây
      Điều này tích lũy mỗi ngày, và khi gần đạt tới 1 giây thì người ta chèn một giây nhuận vào UTC, khiến ngày hôm đó dài 86401 giây thay vì 86400. UTC không chỉ đơn thuần là đếm thời gian đồng hồ nguyên tử, mà còn phải đồng bộ với Mặt Trời vì rất nhiều hoạt động của con người gắn với vị trí của Mặt Trời trên bầu trời
      Con người định nghĩa “đồng bộ với Mặt Trời” là “trong phạm vi 1 giây so với Mặt Trời trung bình”. Tức là muốn chính ngọ UTC nằm trong vòng 1 giây so với chính ngọ Mặt Trời trung bình tại kinh tuyến gốc
      Vì vậy, con số 37 giây có nghĩa là nếu không dùng giây nhuận, thì chính ngọ Mặt Trời trung bình đã bị trễ bao nhiêu so với chính ngọ UTC. Khi UTC đến chính ngọ thì Mặt Trời trung bình vẫn còn thiếu 37 giây nữa mới đi qua kinh tuyến gốc trên bầu trời
    • Theo Wikipedia, tháng 12 năm 2016 là lần gần nhất có chèn giây nhuận: https://en.wikipedia.org/wiki/Leap_second
    • Việc nhắc đến năm 2017 có lẽ là vì đó là lần gần nhất độ lệch này thay đổi. Nên từ thời điểm đó, giá trị -37 giây vẫn tiếp tục có hiệu lực