การประทับเวลา Unix เป็นวันที่

การประทับเวลา Unix เป็นวันที่เป็นเครื่องมือฟรีสำหรับแปลงการประทับเวลา Unix ให้เป็นวันที่ตามเวลา UTC และวันที่เดียวกันในเขตเวลาท้องถิ่นของคุณ

การประทับเวลา Unix คืออะไร?

การประทับเวลา Unix คือตัวเลขที่นับเวลาซึ่งผ่านไปนับตั้งแต่ 00:00:00 UTC ของวันที่ 1 มกราคม 1970 จุดเริ่มต้นนี้เรียกว่า Unix epoch ระบบต่าง ๆ จึงจัดเก็บและเปรียบเทียบช่วงเวลาได้ในรูปแบบกระชับ โดยไม่ขึ้นอยู่กับเขตเวลา

โดยทั่วไป การประทับเวลา Unix จะนับเป็นวินาที แต่ API และภาษาโปรแกรมบางชนิดอาจใช้มิลลิวินาที ไมโครวินาที หรือนาโนวินาที หน่วยไม่ได้ถูกระบุไว้ในตัวเลข คุณจึงต้องตรวจสอบจากเอกสารหรือสคีมาข้อมูลที่เกี่ยวข้อง สำหรับวันที่ในปัจจุบัน ค่าที่มี 10 หลักมักเป็นวินาที ส่วนค่าที่มี 13 หลักมักเป็นมิลลิวินาที อย่างไรก็ตาม จำนวนหลักเป็นเพียงเบาะแส ไม่ใช่หลักเกณฑ์ที่รับประกันได้

นักพัฒนามักต้องแปลงค่านี้เมื่อตรวจสอบคำตอบจาก API ภายนอก อ่านระเบียนในฐานข้อมูล ตรวจดูรายการบันทึก หรือแก้ไขข้อผิดพลาดในการคำนวณวันหมดอายุ นอกจากนี้ยังมีประโยชน์ก่อนนำระบบขึ้นใช้งานจริง เมื่อไฟล์กำหนดค่าเก็บเวลาเปิดใช้งาน เวลาหมดอายุของแคช หรือเวลาหมดอายุของโทเค็นเป็นจำนวนเต็มแทนวันที่ที่อ่านได้

จะแปลงการประทับเวลา Unix เป็นวันที่ได้อย่างไร?

กรอกค่าตัวเลขในช่อง การประทับเวลา Unix แล้วดูค่าที่แปลงแล้วในส่วน UTC และ เขตเวลาท้องถิ่นของคุณ ค่า UTC เป็นค่าอ้างอิงที่คงที่ ส่วนผลลัพธ์ท้องถิ่นจะแสดงเวลาเดียวกันตามค่าชดเชยเขตเวลาของคุณ

1. ตรวจสอบว่าค่าต้นทางเป็นการประทับเวลา Unix จริง
2. ตรวจสอบว่าหน่วยเป็นวินาทีหรือหน่วยที่เล็กกว่า เช่น มิลลิวินาที
3. ใช้ผลลัพธ์ UTC เมื่อต้องเปรียบเทียบระบบ รายการบันทึก หรือข้อมูลจาก API
4. ใช้ผลลัพธ์ท้องถิ่นเมื่อต้องการตรวจสอบว่าเวลานั้นจะแสดงอย่างไรบนนาฬิกาหรือปฏิทินของผู้ใช้

หากเป็นไปได้ ให้ใส่เฉพาะจำนวนเต็ม เว้นวรรค เครื่องหมายคั่นหลัก ป้ายกำกับ และเครื่องหมายวรรคตอนที่คัดลอกมาไม่ได้เป็นส่วนหนึ่งของรูปแบบการประทับเวลา ตัวอย่างเช่น 1,704,067,200 เป็นรูปแบบที่ช่วยให้คนอ่านง่าย แต่ 1704067200 เป็นรูปแบบมาตรฐานที่เครื่องอ่านได้ ตัวอักษรที่มีเครื่องหมายกำกับและอักขระที่ไม่ใช่อักษรละตินไม่มีความหมายในการประทับเวลา Unix

ไม่มีข้อมูลระบุว่าเครื่องมือจัดการกับช่องว่าง ค่าทศนิยม เครื่องหมายคั่น และตัวเลขที่ยาวมากอย่างไร ให้นำข้อความที่อยู่รอบตัวเลขออกและตรวจสอบหน่วยให้แน่ใจก่อนถือว่าวันที่ที่ได้เป็นค่าที่เชื่อถือได้

ควรอ่านผลลัพธ์ UTC และเวลาท้องถิ่นอย่างไร?

ให้มองค่า UTC เป็นเวลาอ้างอิงที่ไม่ขึ้นกับเขตเวลา ส่วนค่าท้องถิ่นคือช่วงเวลาเดียวกันที่ปรับตามเขตเวลาของคุณ ผลลัพธ์ทั้งสองไม่ได้หมายถึงเหตุการณ์คนละเหตุการณ์

ประเทศไทยใช้เวลาเร็วกว่าค่า UTC อยู่ 7 ชั่วโมงตลอดทั้งปีและไม่มีการปรับเวลาออมแสง ดังนั้น การประทับเวลา UTC จะแสดงเป็นเวลาท้องถิ่นที่ช้ากว่า 7 ชั่วโมงเสมอ อย่างไรก็ตาม กฎเขตเวลาทั้งในอดีตและอนาคตอาจส่งผลต่อการแสดงเวลาท้องถิ่นในประเทศหรือเขตเวลาอื่น

หากผลลัพธ์คลาดเคลื่อนจากวันที่ที่ต้องการไปหลายสิบปี สิ่งแรกที่ควรตรวจสอบคือมีการสลับหน่วยระหว่างวินาทีกับมิลลิวินาทีหรือไม่ หากคลาดเคลื่อนตรงกับ 1 ชั่วโมงหรือหลายชั่วโมงพอดี ให้ตรวจสอบการตั้งสมมติฐานเรื่องเขตเวลาแทนการแก้ค่าการประทับเวลา ส่วนผลลัพธ์ที่คลาดเคลื่อนไป 1 วันมักเกิดเมื่อเวลา UTC อยู่ใกล้เที่ยงคืน และค่าชดเชยท้องถิ่นทำให้เลื่อนไปเป็นวันก่อนหน้าหรือวันถัดไป

ข้อมูลที่ไม่ถูกต้องอาจเป็นตัวอักษร ป้ายกำกับที่แทรกอยู่ ค่าว่าง หรือตัวเลขที่อยู่นอกช่วงวันที่ซึ่งระบบปลายทางรองรับ ไม่มีเอกสารระบุข้อความแสดงข้อผิดพลาดที่แน่นอนหรือช่วงตัวเลขที่เครื่องมือรองรับ หากไม่มีผลลัพธ์หรือผลลัพธ์ดูไม่สมเหตุสมผล ให้ตรวจสอบกับระบบต้นทางแทนการคาดเดา

ตัวอย่างการแปลงการประทับเวลา

ตัวอย่างเหล่านี้ใช้การประทับเวลาที่วัดเป็นจำนวนวินาทีเต็ม

ข้อมูลนำเข้า 0

ผลลัพธ์ UTC 1 January 1970 at 00:00:00 UTC

ค่าศูนย์หมายถึงจุดเริ่มต้น Unix epoch การแสดงผลเป็นเวลาท้องถิ่นอาจต่างออกไป หากค่าชดเชยท้องถิ่นที่ใช้ไม่ใช่ UTC

ข้อมูลนำเข้า 1704067200

ผลลัพธ์ UTC 1 January 2024 at 00:00:00 UTC

สำหรับประเทศไทย เวลาดังกล่าวตรงกับ 07:00 น. ของวันเดียวกัน ส่วนการแสดงการประทับเวลาเดียวกันในเขตเวลาที่อยู่ทางตะวันตกของ UTC อาจยังตรงกับวันที่ 31 ธันวาคม 2023

การประทับเวลาที่เป็นค่าลบหมายถึงช่วงเวลาก่อน Unix epoch ตัวอย่างเช่น -1 โดยทั่วไปหมายถึง 1 วินาทีก่อน epoch หรือ 31 December 1969 at 23:59:59 UTC การรองรับค่าลบแตกต่างกันไปตามสภาพแวดล้อมซอฟต์แวร์ ฐานข้อมูล และไลบรารีวันที่

เมื่อใดที่ไม่จำเป็นต้องแปลงการประทับเวลา?

ไม่จำเป็นต้องแปลงหากมีเพียงเครื่องที่อ่านค่านี้ และทุกระบบที่เกี่ยวข้องใช้หน่วยกับ epoch ตรงกันอยู่แล้ว การเก็บค่าเป็นตัวเลขช่วยหลีกเลี่ยงการสร้างวันที่แบบจัดรูปแบบ ซึ่งภายหลังอาจถูกอ่านด้วยรูปแบบท้องถิ่นหรือเขตเวลาที่ไม่ถูกต้อง

• อย่าแปลงการประทับเวลาเพียงเพื่อเปรียบเทียบลำดับก่อนหลัง ค่าตัวเลขที่ใช้หน่วยเดียวกันสามารถเปรียบเทียบกันได้โดยตรง
• อย่าแทนที่ค่าการประทับเวลาแบบตัวเลขที่ API กำหนดด้วยวันที่แบบจัดรูปแบบ เว้นแต่ข้อกำหนดของ API จะอนุญาตรูปแบบนั้น
• อย่าแปลงและอ่านค่าการประทับเวลาซ้ำไปมาระหว่างประมวลผลข้อมูล ให้เก็บค่าต้นฉบับไว้แล้วจัดรูปแบบเมื่อถึงขั้นตอนแสดงผล
• ควรแปลงเมื่อตรวจแก้ระเบียนที่ไม่คุ้นเคย ตรวจสอบเวลาหมดอายุ หรือทบทวนข้อมูลจากภายนอกก่อนนำเข้า

การแปลงออกมาเป็นวันที่ที่อ่านได้ไม่ได้พิสูจน์ว่าค่าต้นทางถูกต้อง การพิมพ์การประทับเวลาผิดยังอาจให้วันที่ที่ดูสมบูรณ์ได้ จึงควรเปรียบเทียบกับเหตุการณ์ทางธุรกิจ ลำดับรายการบันทึก หรือเอกสารของแหล่งข้อมูลด้วย

คำถามที่พบบ่อย

ใช้การประทับเวลาแบบ 13 หลักได้ไหม?

การประทับเวลา 13 หลักสำหรับวันที่ในปัจจุบันมักหมายถึงมิลลิวินาที ไม่ใช่วินาที หากตัวแปลงรับค่าเป็นวินาที ให้หารค่ามิลลิวินาทีด้วย 1,000 ก่อน และเก็บเศษไว้เฉพาะเมื่อปลายทางรองรับเศษส่วนของวินาที ไม่มีข้อมูลระบุว่าเครื่องมือนี้จัดการข้อมูลมิลลิวินาทีอย่างไร คุณจึงควรตรวจสอบหน่วยแยกต่างหาก

การประทับเวลา Unix นับอธิกวินาทีด้วยไหม?

เวลา Unix มาตรฐานไม่ได้แสดงอธิกวินาทีเป็นวินาทีที่มีหมายเลขแยกต่างหาก โดยทั่วไประบบจะจับคู่เวลาเข้ากับการนับอย่างต่อเนื่อง ซึ่งถือว่าแต่ละวันมี 86,400 วินาที Unix แม้ว่าวิธีซิงค์นาฬิกาอาจต่างกันในแต่ละแพลตฟอร์ม สำหรับวันที่ทั่วไปในแอปพลิเคชัน เรื่องนี้แทบไม่ทำให้ผลลัพธ์ที่แสดงเปลี่ยนไป แต่มีความสำคัญกับงานด้านเวลาที่ต้องการความเฉพาะเจาะจง

การประทับเวลาเดียวกันจะแสดงวันที่เหมือนกันทุกที่ไหม?

การประทับเวลาเดียวกันหมายถึงช่วงเวลาเดียวกันทั่วโลก แต่วันที่ตามปฏิทินและเวลาท้องถิ่นอาจต่างกันตามเขตเวลา การประทับเวลาที่ใกล้เที่ยงคืน UTC อาจแสดงเป็นคนละวันในลอนดอน นิวยอร์ก และโตเกียว ควรแลกเปลี่ยนการประทับเวลาในรูปแบบ UTC แล้วใช้รูปแบบท้องถิ่นเฉพาะตอนแสดงผล

ทำไมสเปรดชีตถึงเปลี่ยนค่าการประทับเวลา?

สเปรดชีตอาจแสดงค่าที่ยาวด้วยสัญกรณ์วิทยาศาสตร์ หรือใช้รูปแบบวันที่สำหรับระบบเลขลำดับวันที่ของโปรแกรมเอง ให้นำเข้าคอลัมน์การประทับเวลาเป็นข้อความหรือจำนวนเต็มเมื่อความละเอียดของตัวเลขรองรับ จากนั้นใช้สูตรแปลงที่ระบุไว้อย่างชัดเจน ตรวจสอบด้วยว่าสเปรดชีตไม่ได้ปัดเลขหลักท้ายก่อนนำไปแปลง

ปี 2038 จะเป็นปัญหากับการประทับเวลา Unix ไหม?

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