Trong vài năm qua, tôi đã dành rất nhiều thời gian để debug code test của các engineer khác. Đây là một công việc thú vị, đôi khi gây khó chịu nhưng luôn mang lại nhiều bài học. Có thể ban đầu bạn không nghĩ rằng code test cũng có bug, nhưng tất nhiên mọi code đều có bug và test cũng không phải ngoại lệ.
Tôi đã nhiều lần bối rối khi nhận ra rằng rất nhiều lỗi trong cả code test lẫn code ứng dụng đều bắt nguồn từ những hiểu lầm hoặc nhận thức sai về thời gian. Ở đây tôi muốn nói đến cả cách máy tính xử lý thời gian — vốn khá phức tạp — lẫn những “cái bẫy” cơ bản trong cách con người xây dựng lịch, trong đó daylight saving chỉ là phần nổi của tảng băng.
Thực tế, tôi đã thấy quá nhiều những hiểu lầm như vậy xuất hiện trong chương trình của người khác (và cả của chính mình), đến mức tôi nghĩ rằng nên tổng hợp lại một danh sách những vấn đề phổ biến nhất.
Tất cả những giả định dưới đây đều sai
-
Một ngày luôn có 24 giờ.
-
Tháng luôn có 30 hoặc 31 ngày.
-
Một năm luôn có 365 ngày.
-
Tháng Hai luôn có 28 ngày.
-
Bất kỳ khoảng thời gian 24 giờ nào cũng sẽ bắt đầu và kết thúc trong cùng một ngày (hoặc tuần, hoặc tháng).
-
Một tuần luôn bắt đầu và kết thúc trong cùng một tháng.
-
Một tuần (hoặc một tháng) luôn bắt đầu và kết thúc trong cùng một năm.
-
Máy chạy chương trình luôn ở múi giờ GMT.
-
Được rồi, cái đó không đúng. Nhưng ít nhất múi giờ mà chương trình chạy sẽ không bao giờ thay đổi.
-
Thôi được, chắc chắn sẽ không có chuyện múi giờ của môi trường production thay đổi.
-
Đồng hồ hệ thống luôn được đặt đúng theo thời gian địa phương.
-
Đồng hồ hệ thống luôn gần đúng với thời gian địa phương thực tế.
-
Nếu đồng hồ hệ thống sai, thì ít nhất nó luôn sai lệch một số giây cố định.
-
Đồng hồ server và client luôn giống nhau.
-
Đồng hồ server và client luôn gần giống nhau.
-
Được rồi, nhưng thời gian giữa server và client chắc chắn không thể lệch nhau đến hàng chục năm.
-
Nếu server và client không đồng bộ, thì ít nhất độ lệch cũng luôn cố định.
-
Server và client luôn dùng cùng múi giờ.
-
Đồng hồ hệ thống sẽ không bao giờ được đặt về quá khứ xa hoặc tương lai xa.
-
Thời gian không có điểm bắt đầu và cũng không có điểm kết thúc.
-
Một phút trên đồng hồ hệ thống luôn có độ dài giống hệt một phút trên mọi đồng hồ khác.
-
Được rồi, ít nhất thì độ dài một phút trên đồng hồ hệ thống cũng gần giống các đồng hồ khác.
-
Thôi được, nhưng một phút trên đồng hồ hệ thống chắc chắn không thể dài hơn một giờ.
-
Bạn đùa tôi à?
-
Đơn vị thời gian nhỏ nhất là một giây.
-
Được rồi, là một mili giây.
-
Không bao giờ cần đặt thời gian hệ thống thành giá trị khác ngoài thời gian địa phương đúng.
-
Được rồi, test có thể cần chỉnh thời gian khác, nhưng production thì không bao giờ.
-
Timestamp luôn được biểu diễn ở định dạng phổ biến như 1339972628 hoặc 133997262837.
-
Timestamp luôn có cùng định dạng.
-
Timestamp luôn có cùng độ chính xác.
-
Một timestamp đủ chính xác có thể coi là duy nhất.
-
Timestamp luôn đại diện cho thời điểm sự kiện thực sự xảy ra.
-
Ngày tháng dạng con người đọc được luôn có định dạng chung như 05/07/11.
CẬP NHẬT: Còn nhiều nữa! Hãy đọc tiếp phần còn lại của các ngộ nhận…
Chiếc đồng hồ Citizen Eco-Drive
Cái chuyện “một phút dài hơn một giờ” là đùa thôi đúng không?
Không.
Đã từng có một bug rất thú vị trong các phiên bản cũ của KVM trên CentOS. Cụ thể, một máy ảo KVM không hề “nhận thức” được rằng nó không chạy trên phần cứng thật. Điều này dẫn đến việc nếu hệ điều hành host đưa máy ảo vào trạng thái suspend, đồng hồ hệ thống trong máy ảo sẽ giữ nguyên thời điểm lúc bị suspend.
Ví dụ: nếu VM bị suspend lúc 13:00 và được bật lại sau 2 tiếng (lúc 15:00), đồng hồ trong VM vẫn hiển thị 13:00. Kết quả là mỗi lần VM rảnh, host sẽ suspend nó, và đồng hồ của VM ngày càng lệch xa thực tế — đôi khi rất nhiều, tùy vào thời gian nó bị treo.
Có thể cài một cron job để đồng bộ lại đồng hồ VM với đồng hồ phần cứng của host. Nhưng việc này rất dễ bị quên khi tạo VM mới, và nếu quên thì hậu quả thường khá “hài hước”. Bug này đã được fix ở các phiên bản mới hơn.
Lời cảm ơn
Bài viết này chịu ảnh hưởng rất lớn từ bài blog kinh điển của Patrick McKenzie về user name — một bài mà tôi đã đọc đi đọc lại nhiều lần trong nhiều năm và đã “mượn” không ít về cả ý tưởng lẫn phong cách. Nếu bạn chưa đọc, hãy đọc ngay. Tôi đảm bảo bạn sẽ thích.