Unix Timestamp คืออะไร? Epoch Time, Y2K38 และเวลาทำงานอย่างไรในคอมพิวเตอร์
ทุกครั้งที่คุณส่งข้อความ ซื้อสินค้า หรือโหลดหน้าเว็บ มักมี Unix timestamp บันทึกเวลาที่เกิดเหตุการณ์นั้นเป็นตัวเลขเดียวที่นับวินาทีตั้งแต่วันที่ 1 มกราคม 1970 การเข้าใจระบบนี้เป็นพื้นฐานสำคัญของ web development, database และ systems programming
สารบัญ
Unix Timestamp คืออะไร?
Unix timestamp หรือที่เรียกว่า Epoch time, POSIX time หรือ Unix time คือจำนวนวินาทีที่ผ่านไปตั้งแต่ 1 มกราคม 1970 เวลา 00:00:00 UTC ช่วงเวลานี้เรียกว่า Unix Epoch
ตัวอย่างเช่น timestamp 1000000000 หมายถึง 9 กันยายน 2001 เวลา 01:46:40 UTC หรือหนึ่งพันล้านวินาทีหลัง Epoch ส่วน 0 คือจุดเริ่มต้น และค่าติดลบหมายถึงวันก่อนปี 1970
Unix Epoch: 1970-01-01 00:00:00 UTC -> 0
1 hour later: 1970-01-01 01:00:00 UTC -> 3600
1 day later: 1970-01-02 00:00:00 UTC -> 86400
1 year later: 1971-01-01 00:00:00 UTC -> 31536000
Example: 2026-03-18 00:00:00 UTC -> 1773964800ทำไมต้อง 1 มกราคม 1970?
วันที่นี้ไม่ได้ถูกเลือกแบบสุ่ม แต่เป็นผลจากการออกแบบ Unix ที่ Bell Labs ในช่วงปลายทศวรรษ 1960 และต้นทศวรรษ 1970 ระบบปฏิบัติการต้องการวิธีแทนเวลาแบบเรียบง่าย คำนวณง่าย และเก็บใน integer ได้
Unix รุ่นแรกเคยนับเวลาเป็นหนึ่งในหกสิบส่วนของวินาทีและใช้ epoch ปี 1971 แต่ช่วงเวลาที่แทนได้สั้นเกินไป จึงปรับมาใช้วันที่ 1 มกราคม 1970 และนับเป็นวินาที ทำให้ signed 32-bit integer ครอบคลุมได้ประมาณปี 1901 ถึง 2038
เกร็ดเล็กน้อย
วันที่ 1 มกราคม 1970 เป็นวันพฤหัสบดี จึงมีสูตรคำนวณวันในสัปดาห์จาก timestamp ได้ด้วยการนับจำนวนวันหลัง epoch แล้วปรับ offset ของวันพฤหัสบดี
Unix Timestamp ทำงานอย่างไร
แก่นของ Unix timestamp คือ counter ที่เพิ่มขึ้นทีละ 1 ทุกวินาที การแปลง timestamp เป็นวันที่ต้องคำนึงถึงปี เดือนที่ยาวไม่เท่ากัน ปีอธิกสุรทิน และ timezone offset แต่ในการใช้งานจริงควรใช้ library แทนการคำนวณเอง
ข้อดีคือการเปรียบเทียบเวลากลายเป็นเลขคณิตธรรมดา เหตุการณ์ A เกิดก่อน B หรือไม่ก็เทียบตัวเลขสองตัว ระยะห่างกี่วินาทีก็ลบกันได้ทันที ไม่ต้อง parse string หลายรูปแบบ
Seconds vs Milliseconds
จุดที่ทำให้เกิด bug บ่อยที่สุดคือการสับสนระหว่าง Unix seconds กับ Unix milliseconds
| รูปแบบ | จำนวนหลัก | ตัวอย่าง | ใช้โดย |
|---|---|---|---|
| Seconds | 10 | 1234567890 | Python, PHP, Ruby, Go, C, Unix CLI และ API ส่วนใหญ่ |
| Milliseconds | 13 | 1234567890000 | JavaScript, Java, Dart และ REST API บางระบบ |
| Microseconds | 16 | 1234567890000000 | PostgreSQL และระบบที่ต้องการความละเอียดสูง |
bug คลาสสิก
ถ้าส่ง milliseconds ให้ฟังก์ชันที่คาดหวัง seconds วันที่จะกระโดดไปอนาคตไกลมาก ถ้าส่ง seconds ให้ฟังก์ชันที่คาดหวัง milliseconds มักได้วันที่ในเดือนมกราคม 1970 จำง่าย ๆ คือ 10 หลักมักเป็น seconds และ 13 หลักมักเป็น milliseconds
// JavaScript uses milliseconds
Date.now() // 1773964800000
Math.floor(Date.now() / 1000) // 1773964800
// Python uses seconds
import time
time.time() // 1773964800.123
int(time.time()) // 1773964800
seconds = milliseconds / 1000
milliseconds = seconds * 1000Timestamp และ Timezone
Unix timestamp ไม่ขึ้นกับ timezone เพราะแทนช่วงเวลาเดียวกันบนโลกทั้งใบ ตัวเลข 1773964800 คือ instant เดียวกัน ไม่ว่าผู้ใช้อยู่กรุงเทพฯ นิวยอร์ก หรือลอนดอน ต่างกันแค่รูปแบบเวลาท้องถิ่นที่แสดงผล
Timestamp: 1773964800
UTC: 2026-03-18 00:00:00
Bangkok: 2026-03-18 07:00:00 (UTC+7)
New York: 2026-03-17 19:00:00 (UTC-5)
Tokyo: 2026-03-18 09:00:00 (UTC+9)ระวัง Daylight Saving Time
DST ทำให้เวลาบนหน้าปัดหายไปหนึ่งชั่วโมงหรือซ้ำหนึ่งชั่วโมงในบางประเทศ การเก็บเวลาเป็น UTC timestamp ช่วยลดความกำกวม เพราะค่อยแปลงเป็น local time ตอนแสดงผล
Unix Timestamp ที่น่าสนใจ
| Timestamp | วันที่ UTC | ความหมาย |
|---|---|---|
| 0 | 1 ม.ค. 1970 00:00:00 UTC | จุดเริ่มต้นของ Unix Epoch |
| 1000000000 | 9 ก.ย. 2001 01:46:40 UTC | หนึ่งพันล้านวินาทีหลัง Epoch |
| 1234567890 | 13 ก.พ. 2009 23:31:30 UTC | ลำดับเลขจำง่ายที่ developer ชอบอ้างถึง |
| 2147483647 | 19 ม.ค. 2038 03:14:07 UTC | ค่าสูงสุดของ signed 32-bit Unix time |
ปัญหา Year 2038 หรือ Y2K38
ระบบที่เก็บ Unix timestamp เป็น signed 32-bit integer จะเก็บค่าสูงสุดได้เพียง 2,147,483,647 ซึ่งตรงกับวันที่ 19 มกราคม 2038 เวลา 03:14:07 UTC วินาทีถัดไปจะ overflow กลับไปเป็นค่าติดลบและถูกตีความเป็นปี 1901
32-bit signed integer:
Max: 2,147,483,647 -> 2038-01-19 03:14:07 UTC
Next: 2,147,483,648 -> needs 33 bits
Overflow result: -2,147,483,648 -> 1901-12-13
64-bit signed integer:
Max: 9,223,372,036,854,775,807
Range: hundreds of billions of yearsอะไรเสี่ยงบ้าง?
ระบบ desktop และ server สมัยใหม่ส่วนใหญ่ย้ายไปใช้ 64-bit timestamps แล้ว ความเสี่ยงมักอยู่ใน embedded systems, IoT, อุปกรณ์อุตสาหกรรม ระบบรถยนต์ อุปกรณ์แพทย์ และ file format เก่าที่ยังใช้เวลาแบบ 32-bit
Timestamp ในภาษาโปรแกรมต่าง ๆ
ภาษาโปรแกรมหลักเกือบทั้งหมดมีเครื่องมือจัดการ Unix timestamp ในตัว สิ่งสำคัญคือต้องรู้ว่า API นั้นใช้ seconds หรือ milliseconds
JavaScript / TypeScript
Date.now() // milliseconds
Math.floor(Date.now() / 1000) // Unix seconds
new Date(1773964800 * 1000) // timestamp -> Date
new Date('2026-03-18').getTime() // Date -> millisecondsPython
import time
from datetime import datetime, timezone
time.time() # seconds with decimal
datetime.fromtimestamp(1773964800, tz=timezone.utc)
datetime(2026, 3, 18, tzinfo=timezone.utc).timestamp()Command Line
# Linux / macOS
date +%s
date -d @1773964800
# Windows PowerShell
[DateTimeOffset]::UtcNow.ToUnixTimeSeconds()
[DateTimeOffset]::FromUnixTimeSeconds(1773964800)รูปแบบวันที่ที่ใช้บ่อย
| รูปแบบ | ตัวอย่าง | ใช้กับ |
|---|---|---|
| ISO 8601 | 2026-03-18T00:00:00.000Z | API, JSON, database และ data exchange |
| RFC 2822 | Wed, 18 Mar 2026 00:00:00 +0000 | Email headers และ HTTP headers |
| RFC 3339 | 2026-03-18T00:00:00Z | subset ของ ISO 8601 ที่นิยมใน API |
| Unix seconds | 1773964800 | database, server logs และ API |
| Relative | 3 days ago | ข้อความที่แสดงให้ผู้ใช้ใน social media หรือ comments |
ใช้ ISO 8601 เมื่อแลกเปลี่ยนข้อมูล
วันที่อย่าง 03/04/2026 กำกวมว่าเป็น 3 เมษายนหรือ 4 มีนาคม แต่ 2026-03-04 ชัดเจนกว่าและเรียงลำดับเป็น string ได้ถูกต้อง
ใช้งานจริงที่ไหนบ้าง
Web APIs และ JSON: REST, GraphQL และ JWT มักใช้ timestamp ใน field เช่น iat และ exp
Databases: ใช้เก็บเวลาสร้าง แก้ไข หมดอายุ และ query ตามช่วงเวลา
Log files และ monitoring: ใช้จัดลำดับเหตุการณ์และเชื่อมโยง log จากหลายระบบ
Caching และ TTL: cookie expiry, cache expiration, DNS TTL และ rate limiting ล้วนผูกกับเวลา
Version control: Git เก็บเวลา commit เป็น Unix seconds พร้อม timezone offset
File systems: ไฟล์มี created, modified และ accessed timestamps สำหรับติดตามสถานะ
ข้อผิดพลาดที่พบบ่อย
1. สับสน seconds กับ milliseconds
JavaScript ใช้ milliseconds แต่ Python ใช้ seconds เป็นหลัก ถ้าไม่แปลงหน่วย วันที่จะผิดอย่างมาก
2. ลืม timezone
date string ที่ไม่มี timezone อาจให้ผลต่างกันในเครื่องคนละประเทศ ควรระบุ UTC หรือ offset ให้ชัด
3. เดือนใน JavaScript เริ่มจาก 0
new Date(2026, 3, 18) คือ 18 เมษายน ไม่ใช่ 18 มีนาคม เพราะ January = 0
4. เก็บวันที่เป็นข้อความที่ format แล้ว
ข้อความอย่าง March 18, 2026 เรียงลำดับและแปลง timezone ยากกว่า timestamp หรือ ISO 8601
5. เข้าใจ leap second ผิด
Unix time ถือว่าทุกวันมี 86,400 วินาที และไม่ได้เพิ่ม leap seconds แบบตรง ๆ ซึ่งพอสำหรับงานทั่วไปส่วนใหญ่
แนวทางปฏิบัติที่ดี
- เก็บเป็น UTC: แปลงเป็นเวลาท้องถิ่นเฉพาะตอนแสดงให้ผู้ใช้
- ใช้ 64-bit integers: ลดความเสี่ยงจากปัญหา Year 2038
- ระบุหน่วยให้ชัด: ตั้งชื่อ field เช่น
created_at_msเมื่อเป็น milliseconds - ใช้ ISO 8601 สำหรับ API ที่ต้องอ่านได้: ใส่ timezone offset หรือ
Zสำหรับ UTC - รองรับ edge cases: วันที่ก่อน 1970, เที่ยงคืน, ขอบเขต timezone และ DST
- ใช้ library: อย่าคำนวณวันที่ด้วยมือเมื่อมี timezone, เดือน, leap year หรือ DST เข้ามาเกี่ยวข้อง
แปลง Unix Timestamp ได้ทันที
ใช้ Unix Timestamp Converter ฟรีเพื่อแปลงระหว่าง timestamp กับวันที่ที่อ่านได้ แสดง timestamp แบบ live มีหลายรูปแบบผลลัพธ์ relative time และการแปลงตาม timezone ในเบราว์เซอร์ของคุณ
เปิด Unix Timestamp Converter →แหล่งอ้างอิง
- The Open Group. General Concepts: Seconds Since the Epoch.
- Klyne, G. & Newman, C. (2002). Date and Time on the Internet: Timestamps. RFC 3339.
- ISO. ISO 8601: Date and time representations for information interchange.
- Mozilla Developer Network. Date - JavaScript.