รูปแบบการประทับเวลา

สารบัญ:

• สรุป
  • ประเด็น
  • การตัดสินใจ
  • สถานะ
• รายละเอียด
  • สมมติฐาน
  • ข้อจำกัด
  • จุดยืน
  • ข้อโต้แย้ง
  • นัยยะ
• ที่เกี่ยวข้อง
  • การตัดสินใจที่เกี่ยวข้อง
  • ข้อกำหนดที่เกี่ยวข้อง
  • ผลงานที่เกี่ยวข้อง
  • หลักการที่เกี่ยวข้อง
• หมายเหตุ

สรุป

ประเด็น

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

เราโต้ตอบกับระบบที่มีรูปแบบการประทับเวลาต่างกัน:

• ข้อความ JSON ไม่มีรูปแบบการประทับเวลาเนทีฟ ดังนั้นเราต้องเลือกวิธีแปลงการประทับเวลาเป็นสตริงและแปลงสตริงเป็นการประทับเวลา กล่าวคือวิธีทำให้เป็นอนุกรม/ทำให้กลับเป็นข้อมูล

• บางแอปพลิเคชันตั้งค่าให้ใช้เวลาท้องถิ่นแทนเวลา UTC ซึ่งอาจสะดวกสำหรับโครงการที่ต้องปรับตามเวลาท้องถิ่น เช่น โครงการที่กระตุ้นเหตุการณ์ตามเวลาท้องถิ่น

• บางระบบมีความต้องการและความสามารถด้านความแม่นยำของเวลาต่างกัน เช่น ความละเอียดของเวลาเป็นวินาทีเทียบกับมิลลิวินาทีเทียบกับนาโนวินาที ตัวอย่างเช่น คำสั่ง date ของระบบปฏิบัติการ Linux ใช้ความแม่นยำของเวลาเป็นวินาทีโดยค่าเริ่มต้น ในขณะที่ตลาดหลักทรัพย์ Nasdaq ต้องการความแม่นยำของเวลาเป็นนาโนวินาทีโดยค่าเริ่มต้น

การตัดสินใจ

เราเลือกรูปแบบการประทับเวลามาตรฐาน ISO 8601 ที่มีความแม่นยำระดับนาโนวินาที โดยเฉพาะ "YYYY-MM-DDTHH:MM:SS.NNNNNNNNNZ"

รูปแบบนี้แสดงปี เดือน วัน ชั่วโมง นาที วินาที นาโนวินาที และเขตเวลา Zulu หรือที่เรียกว่า UTC, GMT

สถานะ

ตัดสินใจแล้ว

รายละเอียด

สมมติฐาน

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

เราต้องการรูปแบบที่โดยทั่วไปใช้ง่าย แปลงง่าย และมนุษย์อ่านง่าย

เราต้องการความเข้ากันได้กับระบบภายนอกหลากหลายที่เราควบคุมไม่ได้ เช่น ระบบวิเคราะห์ ระบบฐานข้อมูล ระบบการเงิน

ข้อจำกัด

บางระบบมีข้อจำกัดด้านความแม่นยำของเวลา ตัวอย่างเช่น คำสั่ง date ของระบบปฏิบัติการ macOS พิมพ์ความแม่นยำของเวลาเป็นวินาทีได้ แต่ไม่ถึงนาโนวินาที

จุดยืน

เราพิจารณาตัวเลือกหลายอย่าง:

• Unix epoch กล่าวคือตัวเลขเดียวที่เพิ่มขึ้น

• รูปแบบข้อความกระชับ "YYYYMMDDTHHMMSSNNNNNNNNN"

• การใช้เขตเวลาท้องถิ่นเทียบกับเขตเวลา UTC

ข้อโต้แย้ง

สำหรับการใช้งานทั่วไป เราให้คุณค่ากับความง่ายในการอ่าน/เขียนโดยมนุษย์มากกว่าความเร็ว/ขนาดดิบ

สำหรับการใช้งานทั่วไป เราต้องการรูปแบบที่ทำงานได้ดีในระบบเครื่องและทำงานได้ดีด้วยมือ เช่น การเขียนข้อมูลตัวอย่าง การอ่านเอาต์พุต JSON การ grep ไฟล์บันทึก ฯลฯ

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

นัยยะ

ระบบข้อความและระบบเวลาต่าง ๆ ของเราจะบรรจบกันที่รูปแบบนี้

ที่เกี่ยวข้อง

การตัดสินใจที่เกี่ยวข้อง

เราอาจต้องการวิธีที่รวดเร็ว/ง่ายในการติดตามความแตกต่างของเวลา หรือที่เรียกว่าระยะเวลา ซึ่งทำได้ง่ายด้วยการประทับเวลา Unix epoch

ข้อกำหนดที่เกี่ยวข้อง

เราอาจต้องการปรับการตัดสินใจ เช่น หากเรามีข้อกำหนดที่เกี่ยวข้องสำหรับตราประทับข้อความบันทึกประเภทเฉพาะ เช่น สำหรับ Splunk, Sumo, ELK ฯลฯ

ผลงานที่เกี่ยวข้อง

ตัวจัดรูปแบบและตัวแยกวิเคราะห์ตามภาษา:

• date-fns: Modern JavaScript date utility library
• Crono: date and time library for Rust

ตัวอย่างจาก Rosetta Code:

• System time
• Data format
• Show the epoch

ตัวอย่างจาก SixArm:

• now_string

หลักการที่เกี่ยวข้อง

ย้อนกลับได้ง่าย เราเปลี่ยนไปใช้รูปแบบอื่น เช่น Unix epoch ได้ค่อนข้างง่าย

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

หมายเหตุ

เพิ่มหมายเหตุที่นี่