คำถามที่พบบ่อย ตัวแปลง Timestamp Linux

Q: Unix timestamp คืออะไร?

A: Unix timestamp (หรือที่เรียกว่า POSIX time หรือ epoch time) คือจำนวนวินาทีที่นับตั้งแต่ 00:00:00 UTC ของวันที่ 1 มกราคม 1970 โดยไม่นับ leap seconds เป็นจำนวนเต็มที่เรียบง่ายซึ่งแสดงถึงช่วงเวลาเดียวกันทั่วโลก โดยไม่ขึ้นอยู่กับเขตเวลา

Q: จะแปลง Unix timestamp เป็นวันที่ที่มนุษย์อ่านได้อย่างไร?

A: คุณสามารถแปลง Unix timestamp ได้หลายวิธี:

• ออนไลน์: ใช้ Unix Timestamp Converter ของเราเพื่อการแปลงทันที
• Linux terminal: รัน date -d @1785292800 (บน GNU Linux) หรือ date -r 1785292800 (บน macOS)
• JavaScript: new Date(timestamp * 1000).toISOString()
• Python: datetime.utcfromtimestamp(1785292800)
• PHP: date("Y-m-d H:i:s", 1785292800)

Q: ความแตกต่างระหว่าง timestamp แบบวินาทีและมิลลิวินาทีคืออะไร?

A: timestamp แบบวินาทีมีความยาว 10 หลัก (เช่น 1785292800) timestamp แบบมิลลิวินาทีมีความยาว 13 หลัก (เช่น 1785292800000) เนื่องจากค่าถูกคูณด้วย 1000 Date.now() ของ JavaScript คืนค่าเป็นมิลลิวินาที ในขณะที่ระบบและ API ส่วนใหญ่ใช้วินาที การผสมกันโดยไม่ตั้งใจจะทำให้ได้วันที่ที่ผิดพลาดอย่างมาก — ถ้าใช้มิลลิวินาทีในที่ที่คาดว่าเป็นวินาที จะได้วันที่ที่ไกลออกไปประมาณ 56,000 ปีในอนาคต

ตรวจสอบความละเอียดของแหล่งข้อมูลของคุณทุกครั้งก่อนแปลง หากไม่แน่ใจ ให้นับจำนวนหลัก: 10 หลัก = วินาที, 13 หลัก = มิลลิวินาที

Q: Unix timestamp สามารถแสดงวันที่ก่อนปี 1970 ได้หรือไม่?

A: ได้ วันที่ก่อนวันที่ 1 มกราคม 1970 จะแสดงด้วยจำนวนลบ ตัวอย่างเช่น timestamp -3600 ตรงกับ 23:00:00 UTC ของวันที่ 31 ธันวาคม 1969 ไม่ใช่ทุกเครื่องมือแปลงจะจัดการ timestamp ที่เป็นลบได้อย่างถูกต้อง แต่ตัวแปลงออนไลน์ของเราทำได้ ภาษาโปรแกรมทั้งหมดรองรับการใช้งานนี้

Q: ปัญหา Year 2038 คืออะไร?

A: ปัญหา Year 2038 (หรือที่เรียกว่า Y2K38) เป็นปัญหาการแสดงเวลาที่ส่งผลต่อระบบที่เก็บ timestamp เป็นจำนวนเต็มแบบมีเครื่องหมาย 32 บิต ค่าสูงสุดคือ 2147483647 ซึ่งตรงกับ 03:14:07 UTC ของวันที่ 19 มกราคม 2038 หนึ่งวินาทีต่อมา ค่าจะ overflow ไปเป็น -2147483648 ซึ่งถูกตีความเป็นวันที่ 13 ธันวาคม 1901

ระบบ 64 บิตสมัยใหม่ส่วนใหญ่ไม่ได้รับผลกระทบ แต่อุปกรณ์ฝังตัว ฐานข้อมูลรุ่นเก่า และระบบ 32 บิตบางระบบยังคงมีความเสี่ยง วิธีแก้ไขคือการย้ายไปใช้การแสดงเวลาแบบ 64 บิต ซึ่งให้ช่วงประมาณ 292 พันล้านปี

Q: Unix timestamp คิดรวม leap seconds หรือไม่?

A: ไม่ Unix timestamp จงใจละเลย leap seconds แต่ละวันถือว่ามี 86,400 วินาทีเท่ากัน แม้ว่าจะมีการเพิ่ม leap seconds เข้าไปใน UTC ในระหว่างการเพิ่ม leap seconds Unix timestamp จะไม่เดินหน้าเป็นเวลาหนึ่งวินาที ซึ่งเท่ากับข้าม leap seconds ไป นั่นหมายความว่า Unix timestamp จะคลาดเคลื่อนจากเวลาอะตอมเล็กน้อย (ปัจจุบันประมาณ 27 วินาที) และเพิ่มขึ้นเรื่อยๆ

Q: จะจัดการเขตเวลาเมื่อแปลง Unix timestamp ได้อย่างไร?

A: Unix timestamp แสดงถึงช่วงเวลาเดียวกันทุกที่ในโลก เขตเวลามีความสำคัญเฉพาะเมื่อคุณแสดงผลเป็นวันที่ที่มนุษย์อ่านได้ ควรเก็บ timestamp ในรูปแบบจำนวนเต็มดิบเสมอ และแปลงเป็นเวลาท้องถิ่นเพื่อการแสดงผลเท่านั้น ใช้ชื่อเขตเวลา IANA เช่น America/New_York แทนตัวย่อเช่น EST หรือ PST เนื่องจากตัวย่อไม่ได้คำนึงถึงเวลาออมแสง Unix Timestamp Converter ของเราแสดงผลลัพธ์ในหลายเขตเวลาพร้อมกัน

Q: Unix timestamp สูงสุดคือเท่าใด?

A: ค่าสูงสุดขึ้นอยู่กับขนาดของจำนวนเต็มที่ใช้จัดเก็บ:

• จำนวนเต็มแบบมีเครื่องหมาย 32 บิต: 2147483647 (03:14:07 UTC ของวันที่ 19 มกราคม 2038)
• จำนวนเต็มแบบไม่มีเครื่องหมาย 32 บิต: 4294967295 (06:28:15 UTC ของวันที่ 7 กุมภาพันธ์ 2106)
• จำนวนเต็มแบบมีเครื่องหมาย 64 บิต: 9223372036854775807 (ประมาณ 292 พันล้านปีนับจากนี้)

ระบบสมัยใหม่ส่วนใหญ่ใช้จำนวนเต็ม 64 บิต ซึ่งให้ช่วงที่กว้างมากจนแทบไม่มีที่สิ้นสุด การเก็บ timestamp ในคอลัมน์ฐานข้อมูลหรือโครงสร้างข้อมูลเป็นชนิด 64 บิต (BIGINT ใน SQL) เป็นวิธีที่ปลอดภัยในระยะยาว