Lập trình · 22/09/2026

Xử lý ngày giờ trong backend: UTC, múi giờ và khoảng thời gian

Một đơn hàng được tạo lúc 00:15 ở Việt Nam có thể mang ngày hôm trước khi biểu diễn bằng UTC. Nếu backend lấy ngày UTC để lọc báo cáo theo ngày Việt Nam, truy vấn vẫn chạy nhưng kết quả sai. Lỗi ngày giờ thường nằm ở ý nghĩa dữ liệu và ranh giới truy vấn, không phải ở hàm định dạng.

Bài viết hướng dẫn thiết kế dữ liệu thời gian, chuyển ngày địa phương thành khoảng UTC và kiểm tra đầu vào bằng PHP 8.2 trở lên. SQL dùng PostgreSQL và mang tính minh họa; cần kiểm thử trên schema, driver và dữ liệu của ứng dụng trước khi triển khai.

1. Phân biệt thời điểm, ngày và lịch lặp

Dữ liệu	Ý nghĩa	Gợi ý mô hình
Đơn hàng được tạo lúc nào?	Một thời điểm xác định	Timestamp biểu diễn nhất quán theo UTC
Ngày sinh	Ngày trên lịch, không phải thời điểm	Kiểu date, không tự gắn nửa đêm UTC
Gửi báo cáo mỗi ngày lúc 09:00	Giờ địa phương và quy tắc lặp	Giờ, tên múi giờ, quy tắc và chính sách xử lý ngoại lệ
Tác vụ mất bao lâu?	Khoảng thời gian đã trôi qua	Số đo duration với đơn vị rõ ràng

“Lưu tất cả bằng UTC” phù hợp với thời điểm phát sinh sự kiện, nhưng không thay thế việc mô hình hóa ngày sinh hay lịch lặp. Với lịch tương lai, giữ tên múi giờ như Asia/Ho_Chi_Minh cùng ý định của người dùng; một offset riêng lẻ không mô tả đầy đủ quy tắc của mọi vùng.

2. Thống nhất hợp đồng API và database

Đề xuất cho trường thời điểm: API nhận và trả chuỗi có offset rõ ràng, chẳng hạn 2026-09-22T00:15:00+07:00 hoặc dạng UTC tương đương 2026-09-21T17:15:00Z. Từ chối chuỗi thiếu múi giờ nếu hợp đồng không quy định cách diễn giải. Trường ngày riêng dùng YYYY-MM-DD và không tự chuyển múi giờ.

Theo tài liệu PostgreSQL, timestamptz lưu thời điểm dưới dạng UTC, không giữ tên múi giờ ban đầu; khi hiển thị, giá trị được chuyển theo timezone của phiên. Nếu nghiệp vụ cần tên múi giờ gốc, lưu thêm trường riêng. timestamp without time zone không mang cùng ngữ nghĩa này.

Đặt quy ước rõ cho kết nối database, worker và log. Không sửa dữ liệu cũ chỉ vì màn hình hiển thị lệch giờ: trước tiên xác định dữ liệu thực sự sai hay chỉ đang được hiển thị bằng một múi giờ khác.

3. Lọc ngày địa phương bằng khoảng nửa mở

Ngày 22/09/2026 tại Việt Nam tương ứng khoảng UTC từ 2026-09-21T17:00:00Z đến trước 2026-09-22T17:00:00Z. Dùng điều kiện start <= created_at < end: nhận đầu ngày, loại đúng đầu ngày tiếp theo.

Tránh đặt cuối ngày thành 23:59:59 vì dữ liệu có phần giây có thể bị bỏ sót. Hai khoảng ngày liên tiếp dùng cùng một ranh giới sẽ không nhận trùng bản ghi tại nửa đêm. Cũng không mặc định một ngày địa phương luôn bằng 86.400 giây khi hệ thống phục vụ vùng có đổi giờ mùa hè.

4. Ví dụ PHP: kiểm tra ngày rồi chuyển ranh giới

createFromFormat có thể chuẩn hóa ngày vượt phạm vi thay vì chỉ trả lỗi. Vì vậy, mã dưới kiểm tra hình dạng, cảnh báo và kết quả định dạng ngược. Dấu ! đặt lại phần thời gian; getLastErrors có thể trả false khi không có lỗi từ PHP 8.2.

<?php
declare(strict_types=1);

function utcDayBounds(string $day, string $zone): array
{
    if (!preg_match('/\A[0-9]{4}-[0-9]{2}-[0-9]{2}\z/', $day)) {
        throw new InvalidArgumentException('Expected YYYY-MM-DD');
    }
    $local = DateTimeImmutable::createFromFormat(
        '!Y-m-d', $day, new DateTimeZone($zone)
    );
    $errors = DateTimeImmutable::getLastErrors();
    if ($local === false
        || ($errors !== false && ($errors['warning_count'] || $errors['error_count']))
        || $local->format('Y-m-d H:i:s') !== $day.' 00:00:00') {
        throw new InvalidArgumentException('Invalid date or unsupported midnight');
    }
    $end = $local->modify('+1 day');
    if ($end->format('H:i:s') !== '00:00:00') {
        throw new InvalidArgumentException('Unsupported midnight transition');
    }
    $utc = new DateTimeZone('UTC');
    return [$local->setTimezone($utc), $end->setTimezone($utc)];
}

[$start, $end] = utcDayBounds('2026-09-22', 'Asia/Ho_Chi_Minh');
echo $start->format(DateTimeInterface::ATOM), PHP_EOL;
echo $end->format(DateTimeInterface::ATOM), PHP_EOL;

Kết quả là 2026-09-21T17:00:00+00:00 và 2026-09-22T17:00:00+00:00. Điểm quan trọng: tính ngày tiếp theo trong múi giờ địa phương rồi mới chuyển cả hai mốc sang UTC.

Ví dụ hướng tới ngày thông thường ở Việt Nam và các ca kiểm thử New York bên dưới, không phải thư viện xử lý mọi chuyển đổi múi giờ lịch sử. Mã từ chối nửa đêm bị chuẩn hóa sang giờ khác; ứng dụng phục vụ mọi vùng cần chính sách và kiểm thử bổ sung cho ngày bị bỏ qua hoặc nửa đêm mơ hồ. Tên múi giờ không hợp lệ cũng phải được xử lý thành lỗi đầu vào ở lớp API.

5. Truy vấn PostgreSQL bằng tham số

SELECT id, created_at
FROM orders
WHERE created_at >= CAST(:start AS timestamptz)
  AND created_at < CAST(:end AS timestamptz)
ORDER BY created_at, id;

Ví dụ giả định created_at là timestamptz. Bind :start và :end bằng hai chuỗi có offset từ ví dụ PHP, không ghép trực tiếp đầu vào vào SQL. Trong ứng dụng đa khách hàng, bổ sung điều kiện phạm vi truy cập như tenant hoặc chủ sở hữu; lọc ngày không thay thế phân quyền.

Giữ phép so sánh trên cột gốc giúp truy vấn có thể tận dụng chỉ mục phù hợp; không đảm bảo database luôn chọn index. Hãy xem execution plan trên dữ liệu đại diện trước khi kết luận hiệu năng. Đừng chuyển múi giờ từng dòng chỉ để tạo hai ranh giới vốn có thể tính một lần.

6. Các ca kiểm thử cần có

Ngày Việt Nam nêu trên có đúng hai mốc UTC và độ dài 24 giờ.
2026-02-30, chuỗi thiếu số 0 và chuỗi có ký tự thừa phải bị từ chối.
2024-02-29 hợp lệ; 2026-02-29 không hợp lệ.
Với America/New_York, ngày 2026-03-08 dài 23 giờ, ngày 2026-11-01 dài 25 giờ trong bộ quy tắc đang dùng.
Bản ghi đúng start được nhận; bản ghi đúng end bị loại; bản ghi ngay trước end vẫn thuộc ngày đang xét.
Chạy kiểm thử tích hợp với timezone phiên database khác nhau và kiểm tra kết quả vẫn giữ nguyên ý nghĩa.

Giữ cơ sở dữ liệu múi giờ của môi trường được cập nhật. Với lịch lặp ở vùng đổi giờ, quyết định rõ giờ không tồn tại sẽ bỏ qua hay dời, giờ xuất hiện hai lần sẽ chạy một hay hai lần; không để hành vi mặc định vô tình trở thành quy tắc nghiệp vụ.

7. Checklist trước khi đưa vào ứng dụng

Định nghĩa loại dữ liệu cho từng trường: thời điểm, ngày, lịch hay duration.
Quy định múi giờ báo cáo theo người dùng hoặc tổ chức, không lấy ngầm từ server.
Kiểm tra chặt đầu vào và luôn truyền timezone khi chuyển đổi.
Dùng khoảng nửa mở, bind tham số và giữ điều kiện phân quyền.
Kiểm thử ngày nhuận, đổi giờ và ranh giới phần giây.
Phân biệt kiểm thử hàm chuyển đổi với kiểm thử truy vấn thực tế.

Thiết kế ngày giờ tốt bắt đầu từ câu hỏi “giá trị này có nghĩa gì?”. Khi ý nghĩa, múi giờ và ranh giới đã rõ, mã xử lý trở nên dễ kiểm thử hơn và báo cáo ít gặp lỗi lệch ngày khó phát hiện.