การแปลง Unix Timestamp ตามเขตเวลา: คู่มือปฏิบัติ
เหตุใดเขตเวลาจึงสำคัญสำหรับ Unix Timestamp
Unix timestamp เองนั้น ไม่ขึ้นอยู่กับเขตเวลา — ตัวเลข 1785292800 หมายถึงช่วงเวลาเดียวกันทุกที่ ความซับซ้อนเกิดขึ้นเมื่อแปลงช่วงเวลานั้นเป็นเวลาท้องถิ่นที่มนุษย์อ่านได้สำหรับการแสดงผล การบันทึก หรือการวิเคราะห์ข้อมูล
หลักการสำคัญ: เก็บใน UTC เสมอ แปลงเพื่อการแสดงผลเท่านั้น กฎนี้กำจัดบั๊กทั้งหมวดหมู่และทำให้ข้อมูลของคุณพกพาได้ข้ามเขตเวลา
UTC vs เวลาท้องถิ่น: การเข้าใจความแตกต่าง
UTC (Coordinated Universal Time)
UTC คือมาตรฐานเวลาหลัก มันไม่เคยเปลี่ยนแปลงสำหรับเวลาออมแสงและเหมือนกันทุกที่บนโลก Unix timestamp ถูกกำหนดใน UTC
เวลาท้องถิ่น
เวลาท้องถิ่นคือ UTC ที่ปรับสำหรับภูมิภาคทางภูมิศาสตร์ที่เฉพาะเจาะจง มันสามารถแตกต่างจาก UTC ด้วยค่าชดเชยคงที่ (เช่น UTC+8 สำหรับเวลามาตรฐานจีน) หรือค่าชดเชยที่แปรผัน (เช่น Eastern Time สลับระหว่าง UTC-5 และ UTC-4 สำหรับ DST)
ปัญหาค่าชดเชย
Unix timestamp เดียวกันให้เวลาท้องถิ่นที่แตกต่างกันขึ้นอยู่กับตำแหน่งของผู้สังเกต:
| Timestamp | UTC | New York (EST) | Tokyo (JST) | London (BST) | |-----------|-----|----------------|-------------|--------------| | 1785292800 | 2026-07-19 00:00 | 2026-07-18 20:00 | 2026-07-19 09:00 | 2026-07-19 01:00 | | 1785379200 | 2026-07-19 23:59 | 2026-07-19 19:59 | 2026-07-20 08:59 | 2026-07-20 00:59 |
เวลาออมแสง (DST)
DST คืออะไร?
Daylight Saving Time คือแนวปฏิบัติในการเลื่อนนาฬิกาไปข้างหน้าในช่วงเดือนฤดูร้อนเพื่อให้มีแสงในช่วงเย็นนานขึ้น นาฬิกา "spring forward" (เสียหนึ่งชั่วโมง) ในฤดูใบไม้ผลิและ "fall back" (ได้หนึ่งชั่วโมง) ในฤดูใบไม้ร่วง
ผลกระทบต่อการแปลง Timestamp
DST สร้าง ค่าชดเชยที่แปรผัน ระหว่างเวลาท้องถิ่นและ UTC ซึ่งหมายความว่า:
- เวลาท้องถิ่นเดียวกันสามารถตรงกับ timestamp สองค่าที่แตกต่างกัน (ในช่วงการเปลี่ยนผ่าน "fall back" ชั่วโมง 1:00 น. เกิดขึ้นสองครั้ง)
- เวลาท้องถิ่นบางค่าไม่มีอยู่จริง (ในช่วงการเปลี่ยนผ่าน "spring forward" เช่น 2:00 น. ไม่เคยเกิดขึ้น — นาฬิกากระโดดตรงไปที่ 3:00 น.)
ตัวอย่าง: ชั่วโมงที่คลุมเครือ
ในเขตเวลา Eastern Time ของสหรัฐอเมริกา ในวันอาทิตย์แรกของเดือนพฤศจิกายนเวลา 2:00 น. นาฬิกาจะ fall back ไปที่ 1:00 น. ซึ่งหมายความว่า:
from datetime import datetime, timezone
import pytz
eastern = pytz.timezone("America/New_York")
# การเกิดครั้งแรกของ 1:00 น. (EDT, UTC-4)
first = eastern.localize(datetime(2026, 11, 1, 1, 0), is_dst=True)
print(first.timestamp())
# ค่า timestamp บางค่า
# การเกิดครั้งที่สองของ 1:00 น. (EST, UTC-5) = ช้ากว่า 3600 วินาที!
second = eastern.localize(datetime(2026, 11, 1, 1, 0), is_dst=False)
print(second.timestamp())
# first.timestamp() + 3600
จัดการชั่วโมง fall back ที่คลุมเครืออย่างระมัดระวังในแอปพลิเคชันของคุณเสมอ การใช้แฟล็ก is_dst/ambiguous ใน Python หรือตัวเลือกที่เทียบเท่าในภาษาอื่นป้องกันบั๊กที่ซ่อนเร้น
การแปลงข้ามเขตเวลา
ใช้เครื่องมือออนไลน์ของเรา
วิธีที่ง่ายที่สุดสำหรับการแปลงครั้งเดียวคือ Unix Timestamp Converter ของเรา ซึ่งแสดงผลลัพธ์ในหลายเขตเวลาพร้อมกัน
ใช้ Linux Command Line
# แสดง timestamp ในหลายเขตเวลา
TZ="America/New_York" date -d @1785292800
TZ="Europe/London" date -d @1785292800
TZ="Asia/Tokyo" date -d @1785292800
# ด้วยรูปแบบ ISO ที่กำหนดเอง
TZ="UTC" date -d @1785292800 +"%Y-%m-%d %H:%M:%S %Z"
# ผลลัพธ์: 2026-07-19 00:00:00 UTC
TZ="Asia/Shanghai" date -d @1785292800 +"%Y-%m-%d %H:%M:%S %Z"
# ผลลัพธ์: 2026-07-19 08:00:00 CST
ใช้ Python
from datetime import datetime
from zoneinfo import ZoneInfo # Python 3.9+
ts = 1785292800
# แปลงเป็นหลายเขตเวลา
timezones = ["America/New_York", "Europe/London", "Asia/Tokyo", "Australia/Sydney"]
for tz_name in timezones:
tz = ZoneInfo(tz_name)
dt = datetime.fromtimestamp(ts, tz=tz)
print(f"{tz_name}: {dt.strftime('%Y-%m-%d %H:%M:%S %Z')}")
ใช้ JavaScript
const ts = 1785292800;
const date = new Date(ts * 1000);
const timezones = [
"America/New_York",
"Europe/London",
"Asia/Tokyo",
"Australia/Sydney"
];
for (const tz of timezones) {
const str = date.toLocaleString("en-US", {
timeZone: tz,
timeZoneName: "short",
});
console.log(`${tz}: ${str}`);
}
ใช้ Go
package main
import (
"fmt"
"time"
)
func main() {
t := time.Unix(1785292800, 0)
timezones := []string{
"America/New_York",
"Europe/London",
"Asia/Tokyo",
"Australia/Sydney",
}
for _, tz := range timezones {
loc, _ := time.LoadLocation(tz)
fmt.Printf("%s: %s\n", tz, t.In(loc).Format("2006-01-02 15:04:05"))
}
}
รูปแบบการแปลงเขตเวลาที่พบบ่อย
การแปลง Server Logs เป็นเวลาท้องถิ่น
Server logs มักบันทึก timestamp ใน UTC เมื่อวิเคราะห์ ให้แปลงเป็นเขตเวลาท้องถิ่นของคุณ:
# อ่านไฟล์ล็อกและแสดง timestamp ในเวลา Pacific
while IFS= read -r line; do
if [[ $line =~ ^([0-9]+) ]]; then
ts="${BASH_REMATCH[1]}"
TZ="America/Los_Angeles" date -d @"$ts" "+%Y-%m-%d %H:%M:%S"
echo " $line"
fi
done < server.log
การนัดหมายกิจกรรมข้ามเขตเวลา
เมื่อแชร์เวลากิจกรรมข้ามเขตเวลา ให้สื่อสารใน UTC หรือแชร์ Unix timestamp โดยตรงเสมอ สิ่งนี้ขจัดความคลุมเครือ:
- "ประชุมที่
1785292800" ไม่มีความคลุมเครือ - "ประชุมที่ 9:00 น. EST" กลายเป็นความคลุมเครือในช่วงการเปลี่ยนผ่าน DST
- "ประชุมที่ 9:00 น. America/New_York" ดีกว่าแต่ยังต้องรู้สถานะ DST
การเก็บ Timestamp ในฐานข้อมูล
-- เก็บตัว timestamp เองเสมอ (ไม่ขึ้นกับเขตเวลา)
INSERT INTO events (occurred_at, user_id) VALUES (1785292800, 42);
-- หรือเก็บด้วยคอลัมน์ UTC timestamp ที่ชัดเจน
INSERT INTO events (occurred_at_utc, user_id)
VALUES ('2026-07-19 00:00:00+00', 42);
สรุปแนวปฏิบัติที่ดีที่สุด
- เก็บใน UTC, แปลงเพื่อการแสดงผล — อย่าเก็บเวลาท้องถิ่นในฐานข้อมูล
- ใช้ชื่อเขตเวลา IANA (เช่น
America/New_York) แทนตัวย่อ (EST, PST) — ตัวย่อมีความคลุมเครือและไม่คำนึงถึง DST - จัดการ DST อย่างชัดเจน — ใช้ไลบรารีที่รับรู้เขตเวลา; อย่าบวกหรือลบชั่วโมงด้วยตนเอง
- ส่งข้อมูลเขตเวลาเสมอ — เมื่อรับวันที่จากผู้ใช้ ให้เก็บเขตเวลา ไม่ใช่แค่ค่าชดเชย
- ทดสอบวันที่ขอบ — ทดสอบตรรกะการแปลงของคุณในวันที่เปลี่ยนผ่าน DST (ทั้งฤดูใบไม้ผลิและฤดูใบไม้ร่วง) เพื่อจับบั๊กตั้งแต่เนิ่นๆ
ฐานข้อมูลเขตเวลา
ข้อมูลเขตเวลาของระบบของคุณมาจาก IANA Time Zone Database (หรือที่เรียกว่า Olson database) ซึ่งถูกอัปเดตหลายครั้งต่อปีเมื่อรัฐบาลเปลี่ยนกฎ DST อัปเดตระบบของคุณอยู่เสมอ:
# Debian / Ubuntu
sudo apt update && sudo apt install tzdata
# macOS
# อัปเดตอัตโนมัติผ่านการอัปเดตซอฟต์แวร์
# ตรวจสอบเวอร์ชันฐานข้อมูลของคุณ
zdump -v /etc/localtime | head -1
ใช้ Unix Timestamp Converter ของเราสำหรับการแปลงที่คำนึงถึงเขตเวลาอย่างรวดเร็วในทุกเขตเวลาหลัก