แปลง Unix Timestamp

Unix Timestamps ไม่ต้องปวดหัวอีกต่อไป

ถามนักพัฒนาสามคนว่าตอนนี้กี่โมง คุณอาจได้คำตอบสามแบบขึ้นอยู่กับว่าพวกเขาอยู่ที่ไหน แต่ถามค่า Unix timestamp แล้วคุณจะได้ตัวเลขเดียว ซึ่งเหมือนกันสำหรับทุกคนบนโลก จำนวนเต็มเดียวนั้นแหละคือเหตุที่ epoch time ค่อยๆ เป็นรากฐานของเกือบทุก log file แถวฐานข้อมูล และ API response ที่คุณจะสัมผัสเลย หน้านี้อธิบายว่าตัวเลขนั้นหมายความว่าอะไร วิธีอ่านในทั้งสองทิศทาง และมักทำให้คนสะดุดตรงไหน

Epoch time คือตัวนับเดียวที่เดินไปข้างหน้านับตั้งแต่ปี 1970

Unix time คืออะไรจริงๆ

Unix timestamp คือจำนวนวินาทีที่ผ่านไปนับตั้งแต่ 00:00:00 UTC วันที่ 1 มกราคม 1970 โดยไม่นับ leap seconds ช่วงเวลานั้นเรียกว่า epoch และถูกเลือกโดยวิศวกร Unix ยุคแรกเพียงเพราะเป็นวันที่กลมๆ ที่สะดวกในการนับจาก ณ epoch ค่านั้นคือ 0 พอดี ทุกวินาทีที่ผ่านไปเพิ่มหนึ่ง ดังนั้นตัวเลขจึงโตขึ้นเรื่อยๆ วันที่ก่อนปี 1970 ก็ถูกต้องด้วย แสดงเป็นจำนวนเต็มลบ

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

วินาที มิลลิวินาที และเพื่อนๆ

Unix time แบบคลาสสิกนับวินาทีเต็ม ซึ่งให้ตัวเลขสิบหลักที่คุ้นเคยที่เห็นในปัจจุบัน แต่หลายสภาพแวดล้อมต้องการความละเอียดที่สูงกว่า JavaScript เป็นต้น ทำงานเป็นมิลลิวินาที ผลิตค่าสิบสามหลัก และบางระบบไปไกลกว่านั้นถึงระดับ microseconds หรือ nanoseconds กฎง่ายๆ ที่เชื่อถือได้: ตัวเลขสิบหลักคือวินาที สิบสามหลักคือมิลลิวินาที หากวันที่ที่แปลงแล้วลงเอยประมาณปี 1970 แต่คุณคาดหวังวันปัจจุบัน คุณน่าจะป้อนมิลลิวินาทีเข้าไปในฟิลด์วินาที หรือกลับกัน converter ของเราตรวจสอบขนาดอัตโนมัติเพื่อให้คุณไม่ต้องเดา

ทำไมนักพัฒนาจึงพึ่งพามัน

ข้อดีที่ใหญ่ที่สุดคือ timestamp เป็น timezone-neutral จำนวนเต็ม 1735689600 หมายถึงช่วงเวลาเดียวกันไม่ว่าจะเป็นในโตเกียว เบอร์ลิน หรือเซาเปาโล การเก็บตัวเลขนั้นแทนสตริงที่มีรูปแบบในท้องถิ่นหมายความว่าคุณไม่ต้องสงสัยว่าค่าหนึ่งอยู่กับนาฬิกาใด การเรียงลำดับก็ง่ายเช่นกัน เพราะลำดับตามเวลาก็คือลำดับตัวเลข ดังนั้น database index บน timestamp column จึงเรียงเหตุการณ์ได้ถูกต้องโดยไม่ต้อง parse ใดๆ การคำนวณก็สะอาดเท่ากัน: ช่องว่างระหว่างสองเหตุการณ์คือการลบครั้งเดียว และการเพิ่มหนึ่งวันคือการเพิ่ม 86400 คุณสมบัติเหล่านี้แหละที่เป็นเหตุที่ log, token, cache และ message queue ล้วนใช้ epoch time

การแปลงทั้งสองทิศทาง

การแปลงจาก timestamp เป็นวันที่ที่มนุษย์อ่านได้หมายถึงการนำจำนวนวินาทีมาฉาย project ลงบน calendar แล้ว format ในเขตเวลาที่คุณสนใจ การไปทิศทางอื่น คุณนำปี เดือน วัน และเวลา ตัดสินใจว่ามันแสดงอยู่ใน timezone ใด แล้ว collapse กลับเป็นวินาทีนับจาก epoch เครื่องมือของเราทำทั้งสองทิศทางทันทีและทั้งหมดในเบราว์เซอร์ของคุณ ไม่มีอะไรที่คุณวางออกจากเครื่อง วาง timestamp เพื่อถอดรหัส หรือเลือกวันที่เพื่อ encode และอ่านผลลัพธ์ทั้งใน UTC และเวลาท้องถิ่นของคุณพร้อมกัน

UTC กับเวลาท้องถิ่น กับดักคลาสสิก

Timestamp เองไม่มี timezone มันยึดกับ UTC เสมอ ความสับสนปรากฏขึ้นก็เมื่อคุณแสดงมันเท่านั้น หากคุณแปลง 1700000000 แล้วหน้าจอของคุณแสดงเป็นช่วงเย็น ในขณะที่เพื่อนร่วมงานในประเทศอื่นเห็นบ่าย ไม่มีอะไรเสียหาย คุณทั้งคู่กำลังมองช่วงเวลาเดียวกันที่แสดงในนาฬิกาท้องถิ่นที่ต่างกัน บั๊กแอบเข้ามาเมื่อโค้ดอ่านวันที่ท้องถิ่นเหมือนกับว่ามันเป็น UTC หรือประทับเวลานาฬิกาบนผนังโดยไม่บันทึก offset นิสัยที่ปลอดภัยคือเก็บและส่ง UTC และใช้ offset ท้องถิ่นเฉพาะในช่วงสุดท้ายเมื่อแสดงค่าให้คน เมื่อสงสัย ให้เปรียบเทียบกับบรรทัด UTC ใน converter แทนที่จะเป็นบรรทัดท้องถิ่น

ปัญหาปี 2038

ระบบเก่าหลายระบบเก็บ Unix time ไว้ใน signed 32-bit integer ฟิลด์นั้นหมดพื้นที่หนึ่งวินาทีหลังจาก 03:14:07 UTC วันที่ 19 มกราคม 2038 เมื่อตัวนับ overflow และวนกลับเป็นตัวเลขลบ ซึ่งอาจทำให้วันที่ย้อนกลับไปปี 1901 มันเป็นปัญหาในกลุ่มเดียวกับ Y2K ข่าวดีคือระบบปฏิบัติการและภาษาโปรแกรมสมัยใหม่ส่วนใหญ่ย้ายไปใช้ 64-bit timestamps แล้ว ซึ่งจะไม่ overflow ประมาณ 292,000 ล้านปี ดังนั้นสำหรับโค้ดใหม่มันเป็นเพียงเรื่องในประวัติศาสตร์ที่ควรรู้มากกว่าจะเป็นเหตุฉุกเฉิน

สำหรับตัวช่วยบนเบราว์เซอร์เพิ่มเติม ดูเครื่องมือสำหรับนักพัฒนาของเรา และหากคุณต้องการทำงานกับตัวเลขเอง เครื่องคิดเลขอยู่เพียงคลิกเดียว

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