คู่มือสำหรับนักพัฒนาสำหรับตัวแปลง Unix Timestamp

เรียนรู้การใช้ตัวแปลง Unix timestamp ให้เชี่ยวชาญ เรียนรู้วิธีการแปลงเวลา epoch เป็นวันที่อ่านได้สำหรับมนุษย์ จัดการกับภาษาที่แตกต่างกัน และหลีกเลี่ยงข้อผิดพลาดทั่วไปที่นักพัฒนามักพบ

คู่มือสำหรับนักพัฒนาสำหรับตัวแปลง Unix Timestamp

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

Timestamp ของ Unix คืออะไร และทำไมมันถึงสำคัญ

A digital counter displaying the Unix timestamp 1609459200, alongside details for seconds, milliseconds, and microseconds.

ก่อนที่คุณจะชื่นชมตัวแปลงที่ดีได้อย่างแท้จริง คุณต้องเข้าใจว่าตัวเลขนั้น คืออะไร โดยแก่นแท้แล้ว Timestamp ของ Unix คือการนับวินาทีที่เดินต่อเนื่อง มันติดตามจำนวนวินาทีทั้งหมดที่ผ่านไปนับตั้งแต่ 00:00:00 UTC ของวันที่ 1 มกราคม ค.ศ. 1970 จุดเวลาเฉพาะนั้นเป็นที่รู้จักกันในชื่อ "ยุค Unix" อย่างโด่งดัง

แล้วทำไมถึงใช้วิธีนี้? เพราะความเรียบง่ายและประสิทธิภาพ การเก็บเวลาเป็นจำนวนเต็มตัวเดียวนั้นกะทัดรัดและมีประสิทธิภาพมากกว่าข้อความยาวๆ เช่น "Friday, January 1, 2021 12:00:00 AM GMT" อย่างมหาศาล ทำให้มันเหมาะสมอย่างยิ่งสำหรับหลายพื้นที่หลัก:

  • การจัดเก็บในฐานข้อมูล: Timestamp มีขนาดเล็ก ทำให้การดัชนีและสอบถามทำได้อย่างรวดเร็ว นี่คือชัยชนะอันยิ่งใหญ่สำหรับประสิทธิภาพ
  • Payload ของ API: การส่งตัวเลขเดียวไปกลับนั้นกินแบนด์วิดท์น้อยกว่ามากเมื่อเทียบกับการส่งข้อความวันที่แบบเต็ม ทำให้เวลาตอบสนองเร็วขึ้น
  • ไฟล์บันทึก: เมื่อคุณกำลังวิเคราะห์บันทึกจากหลายสิบระบบที่แตกต่างกัน การมี timestamp ที่เป็นมาตรฐานและไม่ขึ้นกับภาษาจะเป็นตัวช่วยชีวิต
  • การคำนวณ: ต้องการรู้ว่ากระบวนการหนึ่งใช้เวลานานเท่าไหร่? เพียงแค่ลบ timestamp เริ่มต้นออกจาก timestamp สิ้นสุด มันเป็นการคำนวณทางคณิตศาสตร์พื้นฐานของจำนวนเต็ม

วินาที vs. มิลลิวินาที และสิ่งอื่นๆ

Timestamp คลาสสิกของ Unix คือตัวเลข 10 หลัก ที่แสดงถึงวินาที แต่เมื่อเทคโนโลยีพัฒนาไป ความต้องการในการติดตามเวลาที่ละเอียดขึ้นก็เพิ่มขึ้น นี่คือจุดที่คุณจะเริ่มเห็น timestamp ที่มีความยาวต่างๆ กัน และมันเป็นอุปสรรคที่พบบ่อย

นี่คือบทสรุปโดยย่อของสิ่งที่คุณมักจะพบเจอในโลกจริง การสับสนระหว่างรูปแบบหนึ่งกับอีกรูปแบบหนึ่งคือข้อผิดพลาด "off-by-a-thousand" คลาสสิกที่อาจนำไปสู่บั๊กที่ทำให้งงงวยได้มาก

ภาพรวมรูปแบบ Timestamp ของ Unix ที่พบบ่อย

หน่วย หลัก กรณีใช้งานทั่วไป ค่าตัวอย่าง (สำหรับช่วงเวลาเดียวกัน)
วินาที 10 มาตรฐานสำหรับระบบแบ็คเอนด์, ฐานข้อมูล, และ API ส่วนใหญ่. 1609459200
มิลลิวินาที 13 พบได้บ่อยในเทคโนโลยีเว็บ โดยเฉพาะ JavaScript. 1609459200000
ไมโครวินาที 16 ใช้ในการซื้อขายความถี่สูงหรือการคำนวณทางวิทยาศาสตร์. 1609459200000000

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

ปัญหาชื่อดังในปี 2038

ความเรียบง่ายที่สง่างามของ Unix timestamp ก็ได้สร้างระเบิดเวลาที่รอเวลาทำงานนั่นคือ "ปัญหาปี 2038" บนระบบ 32-บิต เก่า ค่า timestamp จะถูกเก็บไว้ในตัวเลขจำนวนเต็มแบบมีเครื่องหมาย 32 บิต ปัญหาคือตัวเลขจำนวนเต็มชนิดนี้มีขีดจำกัด มันไม่สามารถเก็บค่าที่มากกว่า 2,147,483,647.

ใน วันที่ 19 มกราคม 2038 เวลา 03:14:07 UTC จำนวนวินาทีนับตั้งแต่ยุคเริ่มต้น (epoch) จะเกินขีดจำกัดนั้น เมื่อถึงเวลาดังกล่าว ตัวเลขจำนวนเต็มจะ "วนกลับ" กลายเป็นค่าลบ ซึ่งจะทำให้ระบบที่เสี่ยงต่อปัญหาตีความวันที่ย้อนกลับไปในปี 1901 ซึ่งอาจทำให้อุปกรณ์รุ่นเก่าหลายพันล้านเครื่องที่ยังคงใช้งานอยู่ขัดข้อง คุณสามารถรับข้อมูลเชิงลึกเพิ่มเติมเกี่ยวกับ Unix epoch และผลกระทบที่มีได้จากผู้เชี่ยวชาญที่ StrongDM.

โชคดีที่นี่ไม่ใช่สิ่งที่พวกเราส่วนใหญ่ต้องกังวลในชีวิตประจำวัน ระบบสมัยใหม่ส่วนใหญ่ได้ย้ายไปใช้ตัวเลขจำนวนเต็ม 64-บิต สำหรับการนับเวลาแล้ว ตัวเลขจำนวนเต็ม 64 บิตมีขนาดใหญ่มากจนจะไม่ล้นอีกอย่างน้อย 292 พันล้านปี ซึ่งแก้ปัญหาได้อย่างสมบูรณ์แบบ.

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

ทำให้การแปลงเป็นเรื่องง่ายในเบราว์เซอร์ของคุณ

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

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

รับคำตอบทันทีด้วยปุ่มลัดคีย์บอร์ด

ทุกอย่างขึ้นอยู่กับความเร็ว ด้วยเครื่องมืออย่าง ShiftShift การแตะสองครั้งอย่างรวดเร็วที่ปุ่ม Shift (หรือ Cmd+Shift+P บน Mac) จะเปิดแถบคำสั่งขึ้นมา เพียงเริ่มพิมพ์ "timestamp," ตัวแปลงก็จะปรากฏขึ้น วางค่าของคุณ และคุณก็จะได้วันที่ที่อ่านง่ายในทันที

นี่คือลักษณะของมัน — Command Palette พร้อมและรอที่จะแปลงเวลาประทับทันทีทับอยู่บนหน้าปัจจุบันของคุณ

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

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

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

มากกว่าแค่เครื่องมือแบบใช้ทีเดียวจบ

เครื่องมือที่ยอดเยี่ยมในเบราว์เซอร์มักจะไม่ได้มีแค่เครื่องมือเดียว มันเป็นส่วนหนึ่งของชุดเครื่องมือทั้งหมด คุณจะพบว่าตัวเองมักจะใช้ตัวแปลงเวลาประทับร่วมกับฟังก์ชันอื่นๆ

ตัวอย่างเช่น คุณอาจจับคู่มันกับ:

  • ตัวจัดรูปแบบ JSON หรือ SQL เพื่อทำความสะอาดโค้ดบางส่วนก่อนที่คุณจะนำเวลาประทับออกมา
  • เครื่องคิดเลข ในตัว สำหรับคำนวณค่าอย่างรวดเร็วจากค่า epoch (คุณสามารถลองใช้เครื่องมือที่คล้ายกันบน หน้าเครื่องคิดเลขของ ShiftShift เพื่อดูว่ามันทำงานอย่างไร).
  • เครื่องมือ เปรียบเทียบข้อความ สำหรับค้นหาความแตกต่างระหว่างการตอบสนองของ API สองรายการ รวมถึง timestamps ทั้งหมด.

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

การแปลง Timestamp ในโค้ดที่ใช้งานได้จริง

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

Code examples in JavaScript, Python, and SQL for converting a Unix timestamp.

ไม่ว่าคุณจะกำลังจัดการข้อมูลบนเว็บ前端, เขียนสคริปต์ Python, หรือสืบค้นฐานข้อมูล การแปลงเวลา epoch เป็นทักษะพื้นฐาน เราจะพูดถึงสถานการณ์ที่พบบ่อยที่สุด ตั้งแต่การแปลงจำนวน integer ของ epoch ให้เป็นสตริงที่อ่านง่าย แล้วทำทั้งหมดในทิศทางกลับกัน.

การแปลง Timestamp ใน JavaScript

อ็อบเจกต์ Date ของ JavaScript เป็นเครื่องมือหลักของคุณที่นี่ แต่มันมีปัญหาใหญ่ที่มักทำให้นักพัฒนาสับสนอยู่เสมอ: มันทำงานในหน่วย มิลลิวินาที, ไม่ใช่หน่วยวินาที นี่เป็นสาเหตุคลาสสิกของบั๊กเมื่อ frontend ของคุณสื่อสารกับ backend ที่ใช้ timestamp มาตรฐานแบบ 10 หลักอ้างอิงวินาที.

เพื่อแปลง Unix timestamp มาตรฐาน (เป็นวินาที) ให้เป็นอ็อบเจกต์ Date ได้อย่างถูกต้อง คุณต้องคูณมันด้วย 1000.

// A standard 10-digit Unix timestamp (in seconds)
const unixTimestamp = 1672531200;

// Convert to milliseconds, then create a Date object
const dateObject = new Date(unixTimestamp * 1000);

// Format into a readable UTC string
// Output: Sun, 01 Jan 2023 00:00:00 GMT
console.log(dateObject.toUTCString());

ต้องการ timestamp ปัจจุบัน? Date.now() จะให้มันแก่คุณในหน่วยมิลลิวินาที แค่จำไว้ว่าต้องหารด้วย 1000 แล้วปัดเศษลงก่อนส่ง timestamp แบบมาตรฐาน 10 หลักกลับไปยัง API.

การจัดการการแปลงด้วย Python

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

นี่คือวิธีง่ายๆ ในการแปลง timestamp ด้วยไลบรารี datetime:

import datetime

Unix timestamp แบบมาตรฐาน 10 หลัก

unix_timestamp = 1672531200

แปลง timestamp เป็นอ็อบเจ็กต์ datetime

datetime_obj = datetime.datetime.fromtimestamp(unix_timestamp)

จัดรูปแบบเป็นสตริงที่สะอาดและอ่านง่าย

ผลลัพธ์: 2023-01-01 00:00:00

print(datetime_obj.strftime('%Y-%m-%d %H:%M:%S'))
วิธีง่ายๆ นี้ให้วิธีที่สะอาดและเชื่อถือได้ในการจัดการ epoch time ในแอปพลิเคชัน Python ของคุณ และถ้าคุณกำลังทำงานกับโครงสร้างข้อมูลที่ซับซ้อนเช่น JSON ที่มี timestamp คุณอาจพบคำแนะนำเกี่ยวกับการใช้ JSON formatter มีประโยชน์สำหรับการแก้ไขข้อผิดพลาด

การแปลงฐานข้อมูลด้วย SQL

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

Unix timestamp แทบจะเป็นสากล ใช้ใน 90% ภาษาโปรแกรมมิ่ง — จาก Date.now() ของ JavaScript ถึง time.time() ของ Python — ขับเคลื่อนการดำเนินงานหลายล้านล้านครั้งต่อวัน การตั้งค่าโซนเวลาให้ถูกต้องเป็นสิ่งสำคัญ ตัวแปลง unix timestamp ที่เชื่อถือได้สามารถจัดการโซนเวลา IANA ได้มากกว่า 400 โซน ซึ่งช่วยป้องกันข้อผิดพลาดใน 62% ของแอปพลิเคชันทั่วโลกที่ประมาณการไว้ซึ่งไม่ได้จัดการโซนเวลาอย่างชัดเจน คุณสามารถดูรายละเอียดเพิ่มเติมเกี่ยวกับการนำไปใช้ทั่วโลกของเครื่องมือเหล่านี้ได้ที่ Fossa.

สำหรับนักพัฒนา การสามารถจัดรูปแบบ SQL แปลง timestamp และคำนวณความแตกต่างของ epoch โดยไม่ต้องออกจากเครื่องของคุณเป็นชัยชนะด้านประสิทธิภาพการทำงานครั้งใหญ่ วิธีการที่ให้ความสำคัญกับท้องถิ่นก่อนนี้ยังช่วยให้คุณปฏิบัติตามมาตรฐานความเป็นส่วนตัวข้อมูลสมัยใหม่เช่น GDPR และ CCPA.

ตัวอย่าง MySQL

ใน MySQL ฟังก์ชัน FROM_UNIXTIME() คือสิ่งที่คุณจะใช้บ่อยที่สุด มันรับอินพุตเป็น integer แบบ epoch แล้วแปลงให้อยู่ในรูปแบบ DATETIME อย่างเรียบร้อย

SELECT FROM_UNIXTIME(1672531200);
-- ผลลัพธ์: '2023-01-01 00:00:00'
หากต้องการดำเนินการในทิศทางตรงกันข้าม - จากสตริงวันที่กลับไปเป็น timestamp แบบ epoch - ก็เพียงใช้ UNIX_TIMESTAMP().

SELECT UNIX_TIMESTAMP('2023-01-01 00:00:00');
-- ผลลัพธ์: 1672531200

ตัวอย่าง PostgreSQL

PostgreSQL ใช้ฟังก์ชันที่แตกต่างออกไปเล็กน้อยแต่ทรงพลังเช่นกัน: to_timestamp(). ฟังก์ชันนี้จะแปลง Unix timestamp ให้เป็นค่า TIMESTAMP WITH TIME ZONE โดยตรง.

SELECT to_timestamp(1672531200);
-- ผลลัพธ์: 2023-01-01 00:00:00+00
เนื่องจากมันตระหนักถึง timezone ตั้งแต่แรก จึงเป็นตัวเลือกที่ทนทานมากสำหรับแอปพลิเคชันที่ให้บริการกลุ่มผู้ใช้ทั่วโลก ซึ่งความแม่นยำในเรื่องเวลาเป็นสิ่งที่ไม่อาจประนีประนอมได้.

การเชี่ยวชาญการแปลง Timestamp ในเทอร์มินัล

หากคุณทำงานอยู่ใน command line การสลับไปใช้เบราว์เซอร์หรือ GUI เพื่อแปลง timestamp อย่างรวดเร็วนั้นถือเป็นสิ่งที่ขัดจังหวะการทำงานจริงๆ เพราะมันทำให้คุณเสียสมาธิ ข่าวดีก็คือคุณไม่จำเป็นต้องทำเช่นนั้น เพราะทั้ง Linux และ macOS ต่างก็มีเครื่องมือที่ทรงพลังและเป็นระบบดั้งเดิมในการจัดการการแปลงเหล่านี้โดยไม่ต้องออกจากเทอร์มินัลเลย.

เครื่องมือหลักสำหรับงานนี้คือคำสั่ง date ธรรมดาๆ. มันมีอยู่ในระบบ Unix-like เกือบทุกแห่ง แต่มีข้อแม้อยู่อย่างหนึ่ง: ไวยากรณ์สำหรับใช้เป็น unix timestamp convertor นั้นแตกต่างกันระหว่าง Linux (GNU) และ macOS (BSD). การรู้ถึงความแตกต่างคือกุญแจสำคัญในการทำให้ถูกต้องทุกครั้ง.

การแปลง Timestamp บน Linux

บน Linux ไวยากรณ์นั้นเรียบง่ายและจำได้ง่าย คุณเพียงแค่ใช้แฟล็ก -d เพื่อระบุวันที่ แต่คุณต้องแจ้งให้มันทราบว่าคุณกำลังป้อน epoch timestamp โดยใส่ @ ไว้ข้างหน้า.

สมมติว่าคุณกำลังค้นหาในไฟล์บันทึกและพบ timestamp 1704067200. เพื่อดูว่ามันหมายความว่าอะไรจริงๆ คุณจะรันคำสั่งนี้:

date -d @1704067200

คุณจะได้รับวันที่ที่มนุษย์อ่านเข้าใจได้กลับมาทันที เช่น Mon Jan 1 00:00:00 UTC 2024. คุณยังสามารถปรับแต่งผลลัพธ์นั้นด้วยรูปแบบที่กำหนดเองได้.

date -d @1704067200 +"%Y-%m-%d %H:%M:%S"

ผลลัพธ์: 2024-01-01 00:00:00

เคล็ดลับ Pro Tip: คำสั่งนี้จะกลายเป็นเครื่องมือทรงพลังจริงๆ เมื่อคุณเริ่มส่งข้อมูลจากคำสั่งอื่นเข้ามาทาง pipe คุณสามารถ grep เวลาจากไฟล์บันทึกขนาดใหญ่และส่งมันโดยตรงไปยัง date เพื่อการแปลงค่าทันที มันเปลี่ยนงานแก้ไขไขค้นหาข้อผิดพลาดหลายขั้นตอนให้กลายเป็นคำสั่งบรรทัดเดียวที่สง่างาม

การจัดการการแปลงค่าบน macOS

ตอนนี้ หากคุณรันคำสั่งเดียวกันจาก Linux บน Mac มันจะแสดงข้อผิดพลาด เวอร์ชัน BSD ของ date ที่ macOS ใช้ต้องการแฟล็ก -r แทน และไม่ต้องการคำนำหน้า @

นี่คือวิธีที่คุณจะแปลงเวลาเดียวกันบน Mac:

date -r 1704067200

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

date -r 1704067200 +"%Y-%m-%d %T %Z"

ผลลัพธ์: 2024-01-01 00:00:00 UTC

ความแตกต่างเล็กๆ น้อยๆ นี้เป็นอุปสรรคคลาสสิกสำหรับใครก็ตามที่สลับไปมาระหว่าง Linux และ macOS บ่อยๆ การจดจำทั้งสองเวอร์ชันจะช่วยคุณประหยัดปวดหัวได้มากในอนาคต

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

กับดักเวลาทั่วไปและวิธีหลีกเลี่ยง它们

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

ความสับสนระหว่างวินาทีกับมิลลิวินาที

ปัญหาที่พบบ่อยที่สุดคือความสับสนระหว่างวินาทีกับมิลลิวินาที เวลา Unix มาตรฐานเป็นจำนวนเต็ม 10 หลัก ที่แสดงจำนวนวินาทีนับตั้งแต่ยุค (Epoch) แต่ระบบหลายระบบ โดยเฉพาะในโลก JavaScript ทำงานกับเวลา 13 หลัก สำหรับมิลลิวินาที เมื่อแอปพลิเคชันฝั่งหน้าส่งค่ามิลลิวินาทีไปยังฝั่งหลังที่คาดหวังค่าวินาที สิ่งต่างๆ ก็วุ่นวาย

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

กับดักโซนเวลา

อีกหนึ่งข้อผิดพลาดที่แม้แต่นักพัฒนาผู้มากประสบการณ์ก็อาจพ่ายแพ้ คือการจัดการโซนเวลา ตามนิยามแล้ว Unix timestamp จะอยู่ในเวลาสากล (UTC) เสมอ ซึ่งแทนช่วงเวลาสากลเดียว ไม่ขึ้นกับสถานที่ใดๆ ความผิดพลาดเกิดขึ้นเมื่อเราลืมเรื่องนี้แล้วสมมติว่า timestamp แสดงเวลาท้องถิ่นของผู้ใช้

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

กฎทองคือง่ายมาก: ให้จัดการ timestamp เป็น UTC ในฝั่งแบ็กเอนด์เสมอ เก็บรักษาเป็น UTC, ประมวลผลเป็น UTC และค่อยแปลงเป็นเวลาท้องถิ่นของผู้ใช้ในฝั่งฟรอนต์เอนด์เฉพาะตอนแสดงผลเท่านั้น

การแก้ปัญหาข้อผิดพลาดทั่วไปในการแปลง Timestamp

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

อาการ สาเหตุที่เป็นไปได้ วิธีแก้ไข
วันที่แสดงเป็นปี 52361 หรือปีอื่นที่ห่างไกลในอนาคตมิลลิวินาที vs. วินาที. คุณกำลังส่ง timestamp แบบมิลลิวินาที 13 หลัก ไปยังฟังก์ชันที่ต้องการ timestamp แบบวินาที 10 หลัก. หาร timestamp ด้วย 1000 กับดำเนินการ ตรวจสอบจำนวนหลักของ timestamp ที่เข้ามาเสมอ.
เวลาผิดไปไม่กี่ชั่วโมง แต่วันที่ถูกต้อง. การจัดการเขตเวลาผิดพลาด. Timestamp ถูกแปลงโดยใช้เวลาท้องถิ่นของเซิร์ฟเวอร์แทนเวลาของผู้ใช้หรือ UTC. ตรวจสอบให้แน่ใจว่าการแปลงทั้งหมดระบุเขตเวลาเป้าหมายอย่างชัดเจน แปลงเป็นเวลาท้องถิ่นเฉพาะฝั่งไคล언ต์เท่านั้น.
วันที่ค้างอยู่ที่ 1 มกราคม 1970. Timestamp ไม่ถูกต้องหรือเป็น Null. ค่า timestamp อาจเป็น 0, null, หรือ undefined. เพิ่มการตรวจสอบเพื่อให้แน่ใจว่า timestamp เป็นจำนวนเต็มบวกที่ถูกต้องก่อนพยายามแปลง ให้ค่าสำรองไว้.
ได้รับ "Invalid Date" หรือข้อผิดพลาด NaN. ชนิดข้อมูลไม่ถูกต้อง. Timestamp ถูกจัดการเป็นสตริงหรือชนิดที่ไม่ใช่ตัวเลขอื่น ๆ เมื่อจำเป็นต้องใช้ตัวเลข.แปลง Timestamp ให้เป็นจำนวนเต็ม (parseInt() ใน JavaScript, int() ใน Python) อย่างชัดเจนก่อนนำไปใช้ในฟังก์ชันวันที่

จำไว้ว่า การตรวจสอบข้อมูลนำเข้าอย่างรวดเร็วสามารถช่วยประหยัดเวลาแก้ไขปัญหาในภายหลังได้หลายชั่วโมง

หลีกเลี่ยงความกำกวมด้วยรูปแบบมาตรฐาน

การพึ่งพา Timestamp จำนวนเต็มดิบๆ เมื่อส่งข้อมูลระหว่างระบบอาจทำให้เกิดความสับสนได้ นี่คือเหตุผลที่การทำให้เป็นมาตรฐานโดยใช้รูปแบบสตริงสากล เช่น ISO 8601 (2022-05-17T12:00:00Z) จึงเป็นวิธีป้องกันที่ดีมาก การแปลง Unix Timestamp (เช่น 1652905200) เป็นรูปแบบที่ชัดเจนและสามารถอธิบายตัวเองได้เช่นนี้ ช่วยป้องกันข้อผิดพลาดในการเรียก API ข้ามโซนเวลาได้ประมาณ 37% ของกรณีทั้งหมด

เมื่อพิจารณาว่า 72% ของบริษัท Fortune 500 ใช้ Unix Timestamp สำหรับการวิเคราะห์บันทึก ซึ่งความผิดพลาดเพียงเล็กน้อยอาจทำให้ต้องเสียค่าใช้จ่ายมากกว่า $10,000 ต่อชั่วโมงจากการหยุดทำงาน ความแม่นยำจึงเป็นสิ่งสำคัญที่สุด คุณสามารถอ่านเพิ่มเติมเกี่ยวกับวิธีการใช้ Epoch Time ในอุตสาหกรรมต่างๆ ได้ที่ EpochConverter.

สำหรับผู้ที่จัดการฐานข้อมูล การจัดการ Timestamp อย่างสม่ำเสมอก็สำคัญไม่แพ้กัน หากคุณพบว่าตนเองต้องต่อสู้กับรูปแบบ Timestamp ที่แตกต่างกันบ่อยครั้งในฐานข้อมูล คู่มือของเราเกี่ยวกับการใช้ SQL formatter ที่ทรงพลังสามารถช่วยให้คุณรักษาคำสั่ง SQL ของคุณให้สะอาดและคาดเดาได้

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

A flowchart illustrating terminal commands for converting timestamps on Linux and macOS operating systems.

แผนภูมิกระบวนการด้านบนแสดงให้เห็นถึงความแตกต่างของไวยากรณ์ที่สำคัญระหว่างคำสั่ง date บน Linux (-d @...) และ macOS (-r ...) — ซึ่งเป็นกับดักทั่วไปสำหรับนักพัฒนาที่ทำงานในสภาพแวดล้อมที่แตกต่างกัน

เพื่อให้โค้ดของคุณทนทานต่อข้อผิดพลาด ควรตรวจสอบและยืนยันความถูกต้องของ Timestamp ที่รับเข้ามาเสมอ ฟังก์ชันง่ายๆ ที่ตรวจสอบค่า 10 หลัก (วินาที) หรือ 13 หลัก (มิลลิวินาที) สามารถตรวจจับข้อผิดพลาดเหล่านี้ก่อนที่จะไปทำลายตรรกะของแอปพลิเคชันของคุณได้

คำถามที่พบบ่อยเกี่ยวกับ Unix Timestamp

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

ทำไม API จำนวนมากจึงใช้ Timestamp แทน字符串 ISO 8601?

เหตุผลหลักคือประสิทธิภาพดิบๆ Unix timestamp เป็นเพียงตัวเลขเดียว ทำให้มีขนาดเล็กกระทัดรัดอย่างน่าทึ่งเมื่อเทียบกับ字符串如 '2023-10-27T10:00:00Z' ขนาดที่เล็กกว่าหมายความว่าต้องส่งข้อมูลน้อยลงผ่านเครือข่าย ซึ่งช่วยประหยัดแบนด์วิดท์และเร่งการตอบสนองของ API ได้

นอกจากนี้ยังไม่ขึ้นกับภาษาใดๆ ทั้งสิ้น ไม่มีความกำกวม ไม่มีปัญหาการแยกวิเคราะห์ และไม่ต้องกังวลเรื่องรูปแบบเฉพาะภูมิภาค สำหรับเครื่องจักร การคำนวณตัวเลขเร็วกว่าการแยกวิเคราะห์字符串เสมอ ดังนั้นการคำนวณวันที่ใดๆ เช่น การหาช่วงเวลาระหว่างสองเหตุการณ์ จะมีต้นทุนการคำนวณที่ต่ำกว่า สำหรับระบบที่ต้องการประสิทธิภาพสูง ความเรียบง่ายนี้คือข้อได้เปรียบอย่างมาก

วิธีที่ถูกต้องในการจัดการ Timezone คืออะไร?

นี่คือประเด็นสำคัญที่สุด นี่คือกฎทอง: Unix timestamp จะอยู่ใน UTC เสมอ เสมอ มันไม่มีแนวคิดเรื่อง timezone ฝังอยู่ในตัว มันเป็นเพียงจำนวนวินาทีดิบที่นับจากยุคเริ่มต้น (epoch)

Timezone จะมีความสำคัญก็ต่อเมื่อคุณต้องการแสดง timestamp นั้นให้มนุษย์เห็น

คำแนะนำของผม? ยึดหลักใช้ UTC สำหรับทุกอย่างในฝั่งแบ็คเอนด์ เก็บไว้ในฐานข้อมูลเป็น UTC timestamp ส่งผ่าน API ของคุณในรูปแบบ UTC และดำเนินตรรกะทั้งหมดบนเซิร์ฟเวอร์ใน UTC เฉพาะเวลาเดียวที่คุณควรแปลงเป็น timezone ท้องถิ่นคือในฝั่งฟรอนต์เอนด์ ก่อนแสดงผลให้ผู้ใช้เท่านั้น แนวทางปฏิบัตินี้เพียงอย่างเดียวจะช่วยคุณหลีกเลี่ยงปัญหาเกี่ยวกับ timezone และเวลาออมแสงได้ทั้งหมด

ฉันควรกังวลเรื่องปัญหา Year 2038 อยู่หรือไม่?

สำหรับโปรเจกต์ใหม่ส่วนใหญ่ คงไม่จำเป็น "ปัญหา Year 2038" เป็นปัญหาตกค้างจากระบบเก่าๆ ที่ใช้ จำนวนเต็ม 32 บิตแบบมีเครื่องหมาย ในการเก็บ timestamp เมื่อตัวเลขนั้นใหญ่เกินไป มันจะล้นและกลายเป็นค่าลบ ทำให้วันที่ย้อนกลับไปปี 1901

โชคดีที่ระบบทันสมัยเกือบทั้งหมด ตั้งแต่ระบบปฏิบัติการไปจนถึงฐานข้อมูล ได้เปลี่ยนมาใช้ จำนวนเต็ม 64 บิต มานานแล้ว สิ่งนี้เลื่อนปัญหาออกไปไกลมาก (หลายพันล้านปีจริงๆ) จนไม่ใช่ปัญหาในทางปฏิบัติสำหรับเราอีกต่อไป

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

ฉันจะแปลง Timestamp ใน Excel หรือ Google Sheets ได้อย่างรวดเร็วได้อย่างไร?

คุณไม่จำเป็นต้องนำข้อมูลออกมาใช้กับเครื่องมือแปลง Unix timestamp เฉพาะทาง แค่สูตรง่ายๆ ก็เพียงพอ สมมติว่า timestamp ของคุณอยู่ในช่อง A1:

  • สำหรับ timestamp ในหน่วยวินาที (10 หลัก): =A1 / 86400 + DATE(1970,1,1)
  • สำหรับเวลาในรูปแบบมิลลิวินาที (13 หลัก): =A1 / 86400000 + DATE(1970,1,1)

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


เบื่อที่จะต้องสลับไปมาระหว่างโปรแกรมแก้ไข บรรทัดคำสั่ง และแท็บเบราว์เซอร์หลายสิบแท็บสำหรับงานง่ายๆ หรือไม่? ชุด ShiftShift Extensions รวมเอาตัวแปลง Unix timestamp ที่ทรงพลัง, JSON formatter, SQL beautifier และอื่นๆ อีกมากมายไว้ในเบราว์เซอร์ของคุณ ทุกสิ่งที่คุณต้องการอยู่ใกล้แค่ปุ่มลัดบนคีย์บอร์ด

รับ ShiftShift Extensions และทำให้เวิร์กโฟลว์ของคุณง่ายขึ้นวันนี้ที่ https://shiftshift.app

ส่วนขยายที่แนะนำ