Unix Timestamp: định nghĩa, chuyển đổi và lưu trữ trong phát triển di động

Unix Timestamp là gì?

Unix Timestamp (còn được gọi là POSIX time, Epoch time hay Unix time) là một hệ thống đo lường thời gian xác định số giây đã trôi qua kể từ ngày 1 tháng 1 năm 1970 00:00:00 UTC (kỷ nguyên Unix). Ngày này được chọn làm điểm bắt đầu cho hệ điều hành Unix, và sau đó định dạng này đã trở thành tiêu chuẩn thực tế để biểu diễn thời gian trong các hệ thống máy tính. Timestamp không tính đến giây nhuận — mỗi phút được tính là 60 giây, mặc dù Dịch vụ Quay vòng Trái đất Quốc tế đôi khi thêm một giây bổ sung để hiệu chỉnh thời gian nguyên tử.

Kỷ nguyên Unix: tại sao là 1970?

Việc chọn ngày 1 tháng 1 năm 1970 gắn liền với lịch sử của hệ điều hành Unix. Các nhà phát triển Ken Thompson và Dennis Ritchie đã chọn ngày này làm điểm bắt đầu tròn trịa đơn giản — nó đủ sớm để chứa tất cả các ngày có thể, và đủ muộn để thời gian có thể được lưu trữ trong một số nguyên có dấu 32 bit. Ban đầu, thời gian được đo bằng phần sáu mươi của giây, sau đó bằng tick (1/60 giây), và chỉ đến Phiên bản thứ bảy của Unix (V7, 1979), định dạng mới ổn định dưới dạng số nguyên giây. Theo The Open Group Base Specifications (Issue 8, 2024), các hệ thống tương thích POSIX bắt buộc phải hỗ trợ định dạng này.

Cách hoạt động của Unix Timestamp

Nguyên lý hoạt động của Unix Timestamp dựa trên một bộ đếm đơn giản: mỗi ngày trôi qua thêm 86.400 giây vào giá trị. Ví dụ, timestamp 1.720.000.000 tương ứng với một ngày vào giữa năm 2024 — việc chuyển đổi chính xác có thể được thực hiện bằng cách chia cho số giây trong một ngày, một giờ và một phút. Cách tiếp cận này làm cho timestamp trở nên lý tưởng cho việc lưu trữ máy móc: nó là một số nguyên chiếm 4 byte (int 32 bit) hoặc 8 byte (long 64 bit) và hỗ trợ so sánh trực tiếp — timestamp lớn hơn = ngày muộn hơn.

Toán học chuyển đổi

Một ngày = 86.400 giây (24 x 60 x 60). Một giờ = 3.600 giây. Để chuyển đổi timestamp thành ngày, bạn cần tính tuần tự số ngày, giờ, phút và giây kể từ kỷ nguyên. Chuyển đổi ngược lại — chuyển đổi ngày thành số ngày kể từ 1970-01-01, sau đó nhân với 86.400 và cộng thêm độ lệch UTC. Trong Java và Kotlin, các tính toán này đã được triển khai trong các lớp tiêu chuẩn java.time.Instant và java.util.Date, giúp nhà phát triển không cần tính toán thủ công.

        // Lấy Unix Timestamp bằng giây
val seconds = System.currentTimeMillis() / 1000

// Chuyển đổi timestamp thành ngày qua java.time
val instant = Instant.ofEpochSecond(seconds)
val localDate = instant.atZone(ZoneId.of("Europe/Moscow")).toLocalDate()

// Ngược lại: ngày thành timestamp
val date = LocalDate.of(2026, 7, 21)
val ts = date.atStartOfDay(ZoneOffset.UTC).toEpochSecond()

Chuyển đổi Unix Timestamp thành ngày và ngược lại

Chuyển đổi Unix Timestamp thành ngày có thể đọc được bởi con người là một trong những thao tác phổ biến nhất trong phát triển di động. Trên Android, một số phương pháp chuyển đổi có sẵn tùy thuộc vào phiên bản API tối thiểu: đối với API 26+, nên sử dụng java.time.Instant, đối với các phiên bản cũ hơn, sử dụng java.util.Date và java.text.SimpleDateFormat. Điều quan trọng cần nhớ là Android và JVM sử dụng miligiây theo mặc định, không phải giây — nếu timestamp nhận được từ máy chủ tính bằng giây, nó phải được nhân với 1000 trước khi truyền cho các hàm tạo tiêu chuẩn.

Chuyển đổi có tính đến múi giờ

Một trong những lợi thế chính của Unix Timestamp là tính độc lập với vị trí địa lý. Máy chủ luôn trả về timestamp theo UTC, và việc chuyển đổi sang ngày và giờ địa phương được thực hiện ở phía máy khách. Trong Kotlin, ZonedDateTime được sử dụng với ZoneId phù hợp — hoặc hệ thống hoặc do người dùng chọn. Nếu ứng dụng hiển thị thời gian ở các múi giờ khác nhau (ví dụ: cho khách du lịch), timestamp loại bỏ nhu cầu truyền múi giờ từ máy chủ — một dấu thời gian duy nhất là đủ.

// Chuyển đổi với múi giờ người dùng
fun formatTimestamp(seconds: Long, zoneId: ZoneId): String {
    val instant = Instant.ofEpochSecond(seconds)
    val formatter = DateTimeFormatter
        .ofPattern("dd.MM.yyyy HH:mm:ss")
    return formatter.format(instant.atZone(zoneId))
}

// Ví dụ: timestamp = 1720000000, zone = Europe/Moscow
val result = formatTimestamp(1720000000, ZoneId.of("Europe/Moscow"))

Vấn đề năm 2038

Vấn đề năm 2038 (Y2K38) là một giới hạn cơ bản của việc lưu trữ Unix Timestamp dưới dạng số nguyên có dấu 32 bit. Giá trị tối đa của int có dấu 32 bit là 2.147.483.647, tương ứng với ngày 19 tháng 1 năm 2038 lúc 03:14:07 UTC. Sau ngày này, giá trị bị tràn và trở thành số âm, gây ra lỗi trong các hệ thống sử dụng time_t 32 bit. Vấn đề này tương tự như Y2K nổi tiếng, nhưng chủ yếu ảnh hưởng đến hệ thống nhúng, các phiên bản Android cũ và thiết bị IoT có kiến trúc 32 bit.

Quy mô của vấn đề

Theo Linux Foundation (2025), khoảng 15% thiết bị Linux trong phân khúc công nghiệp và IoT vẫn sử dụng bản dựng 32 bit. Đối với thiết bị Android, rủi ro thấp hơn — hầu hết điện thoại thông minh hiện đại chạy trên bộ xử lý 64 bit (ARM64), nhưng các mẫu cũ với Android 4.x trở xuống có thể sử dụng time_t 32 bit. Giải pháp là di chuyển sang time_t 64 bit, an toàn trong tối đa 292 tỷ năm. Bắt đầu từ Android 5.0 (API 21), tất cả thiết bị sử dụng thời gian 64 bit ở cấp độ kernel. Các nhà phát triển ứng dụng di động chỉ cần lưu trữ timestamp dưới dạng Long (64 bit) để tránh vấn đề ở cấp độ ứng dụng.

Làm việc với Unix Timestamp trong Android

Trong phát triển Android, việc xử lý đúng cách Unix Timestamp rất quan trọng cho việc đồng bộ hóa dữ liệu, hiển thị thời gian nhận tin nhắn, tính toán thời gian chờ và lên lịch thông báo. Lệnh gọi hệ thống System.currentTimeMillis() trả về thời gian hiện tại tính bằng miligiây kể từ kỷ nguyên Unix — đây là nguồn thời gian chính xác nhất có sẵn trên thiết bị. Đối với các yêu cầu mạng, Unix Timestamp tính bằng giây thường được sử dụng, vì hầu hết REST API và cơ sở dữ liệu hoạt động bằng giây.

Thực hành được khuyến nghị

Không bao giờ sử dụng System.currentTimeMillis() để đo khoảng thời gian — cho mục đích này, có System.nanoTime(), là đơn điệu và không bị ảnh hưởng bởi thay đổi đồng hồ của người dùng. Để hiển thị thời gian, luôn lưu trữ timestamp ở UTC và chuyển đổi sang múi giờ địa phương ở phía giao diện người dùng. Khi làm việc với cơ sở dữ liệu (SQLite, Room), hãy sử dụng kiểu INTEGER và lưu trữ timestamp tính bằng giây — điều này chiếm 8 byte (Long) và hỗ trợ sắp xếp SQL gốc. Đối với tuần tự hóa JSON, nên gửi timestamp dưới dạng số (Long) thay vì chuỗi — nó nhỏ gọn hơn và phân tích cú pháp nhanh hơn.

// Đo thời gian thực thi chính xác
val start = System.nanoTime()
// ... thao tác ...
val elapsed = System.nanoTime() - start
val seconds = elapsed / 1_000_000_000.0

// Lưu trữ trong Room (Entity)
@Entity
data class Message(
    @PrimaryKey val id: Long,
    val text: String,
    val createdAt: Long // Unix Timestamp bằng giây
)

Xử lý thời gian từ máy chủ

Khi nhận Unix Timestamp từ máy chủ, luôn kiểm tra đơn vị đo lường: một số API trả về miligiây (tương thích JavaScript), một số khác trả về giây (tiêu chuẩn POSIX). Thỏa thuận về đơn vị phải được ghi lại trong tài liệu API. Trong phản hồi của máy chủ, timestamp có thể được truyền dưới dạng Long (số JSON) hoặc String (ISO 8601). Để gỡ lỗi, hãy thêm một hàm tiện ích xuất timestamp ở định dạng con người có thể đọc được — điều này giúp đơn giản hóa việc xác minh dấu thời gian trong quá trình phát triển.

Lưu trữ dấu thời gian trong cơ sở dữ liệu

Việc lựa chọn định dạng lưu trữ thời gian trong cơ sở dữ liệu ảnh hưởng trực tiếp đến hiệu suất truy vấn, độ phức tạp của mã và tính chính xác của việc xử lý múi giờ. Unix Timestamp là định dạng hiệu quả nhất cho cơ sở dữ liệu quan hệ: nó được lưu trữ dưới dạng số nguyên (4 hoặc 8 byte), hỗ trợ lập chỉ mục và cho phép sắp xếp nhanh chóng. Không giống như chuỗi ISO 8601, timestamp không yêu cầu phân tích cú pháp để sắp xếp và chiếm ít không gian hơn trong chỉ mục. Đối với Room và SQLite, nên lưu trữ timestamp dưới dạng INTEGER và sử dụng chỉ mục trên cột thời gian.

Khuyến nghị cho các dự án di động

Đối với các ứng dụng Android sử dụng thư viện Room, nên lưu trữ timestamps dưới dạng Long (64 bit) và sử dụng TypeConverter để chuyển đổi tự động giữa Long và Date hoặc Instant. Khi truy vấn cơ sở dữ liệu, hãy sử dụng toán tử so sánh (>, <, BETWEEN) — chúng hoạt động tự nhiên với các kiểu số nguyên. Để lưu vào bộ nhớ đệm dữ liệu yêu cầu sắp xếp theo thời gian (ví dụ: danh sách tin nhắn), luôn tạo chỉ mục trên cột timestamp — điều này sẽ tăng tốc các truy vấn với ORDER BY lên nhiều bậc độ lớn với khối lượng dữ liệu lớn.