บทความ
คำอธิบาย Unix timestamps และ cron expressions
Unix timestamp คือจำนวนเต็มเพียงตัวเดียว cron expression คือห้าฟิลด์เท่านั้น ทั้งสองปรากฏบ่อยครั้งในงาน backend และทั้งสองทำให้คนสะดุดในรูปแบบที่คาดเดาได้: อย่างแรกเพราะเขตเวลา อย่างหลังเพราะหน่วยวัด
Unix timestamp คืออะไร
Unix timestamp นับจำนวนวินาทีที่ผ่านไปนับตั้งแต่ 1970-01-01 00:00:00 UTC ซึ่งเป็นจุดอ้างอิงที่รู้จักกันในชื่อ Unix epoch คำนิยามนี้มีผลสำคัญสองประการ ประการแรก การนับเป็น UTC: ไม่มีเขตเวลาฝังอยู่ในตัวเลขเอง 1718400000 หมายถึงช่วงเวลาเดียวกันทุกที่บนโลกโดยไม่ขึ้นอยู่กับตำแหน่งของเครื่องที่เก็บมัน ประการที่สอง epoch กำหนดเป็นวินาที ไม่ใช่หน่วยอื่น ค่าอย่าง 1718400000 คือวินาทีนับตั้งแต่เที่ยงคืน 1 มกราคม 1970 UTC เสมอ เว้นแต่ระบบหรือโปรโตคอลจะเลือกแตกต่างอย่างชัดเจน Timestamps ออกแบบมาให้ปลอดจากเขตเวลา ซึ่งนั่นคือเหตุผลที่มันมีประโยชน์สำหรับการบันทึก log ฐานข้อมูล และการสื่อสารระหว่างระบบที่นาฬิกาในภูมิภาคต่าง ๆ ต้องอ้างถึงช่วงเวลาเดียวกันอย่างชัดเจน
วินาที มิลลิวินาที และปัญหาปี 2038
รันไทม์และ API สมัยใหม่หลายตัวใช้มิลลิวินาทีแทนวินาที Date.now() ของ JavaScript คืนค่าเป็นมิลลิวินาที ดังนั้น 1718400000000 คือช่วงเวลาเดียวกับค่าความแม่นยำวินาที 1718400000 เมื่อคุณได้รับ timestamp ที่ไม่คุ้นเคย ขนาดของตัวเลขบอกหน่วย: ตัวเลข 10 หลักเกือบแน่นอนเป็นวินาที ตัวเลข 13 หลักเกือบแน่นอนเป็นมิลลิวินาที ปัญหาปี 2038 เกิดจากการเลือกที่แตกต่าง: การเก็บ timestamp ความแม่นยำวินาทีใน signed 32-bit integer ค่าสูงสุดของ signed 32-bit integer คือ 2147483647 ซึ่งตรงกับ 2038-01-19 03:14:07 UTC หลังจากวินาทีนั้น ตัวนับจะล้นเป็นจำนวนลบขนาดใหญ่และวันที่จะย้อนกลับไปปี 1901 บนระบบที่ไม่จัดการขอบเขต วิธีแก้คือใช้พื้นที่เก็บข้อมูล 64-bit ระบบปฏิบัติการและฐานข้อมูลปัจจุบันส่วนใหญ่ทำเช่นนั้นแล้ว แต่ระบบฝังตัว อุปกรณ์เครือข่าย และรูปแบบไฟล์เก่าที่กำหนดความกว้างของฟิลด์ไว้หลายสิบปีก่อนยังคงมีความเสี่ยง
การแปลง epoch เป็นวันที่ที่มนุษย์อ่านได้: ขั้นตอนเขตเวลา
การแปลงค่า epoch เป็นวันที่ที่อ่านได้ต้องมีสองขั้นตอน: ดึงองค์ประกอบวันที่ UTC จากจำนวนเต็ม จากนั้นใช้ออฟเซ็ต UTC เพื่อรับเวลาท้องถิ่น timestamp เองเป็น UTC เมื่อถามว่า 1718325000 หมายถึงวันที่อะไร คำตอบที่ถูกต้องคือ 2024-06-14 เวลา 00:30 ใน UTC ในนิวยอร์ก (UTC-4 ในฤดูร้อน) วินาทีเดียวกันนั้นตกอยู่ใน 2024-06-13 เวลา 20:30 ของเย็นวันก่อนหน้า: วันที่เปลี่ยน ไม่ใช่แค่ชั่วโมงเปลี่ยน นี่คือขั้นตอนที่ให้ผลผิดเมื่อข้ามไป: นักพัฒนาบันทึก timestamp ดิบใน UTC เครื่องมือรายงานแสดงเป็นเวลาท้องถิ่นโดยไม่แปลง และวันที่ดูเหมือนผิดไปหลายชั่วโมงหรือทั้งวัน เครื่องมือ timestamp-converter บน Sunasty จัดการเรื่องนี้อย่างชัดเจน: คุณป้อนค่า epoch และเครื่องมือจะแสดงวันที่และเวลา UTC ควบคู่กับวันที่และเวลาท้องถิ่นของอุปกรณ์คุณเอง ทำให้เห็นการข้ามขอบวันแบบนี้ได้ในทันที การแปลงทำงานในเบราว์เซอร์ทั้งหมดและสิ่งที่คุณวางไม่ถูกส่งไปไหนเลย
Cron syntax: ห้าฟิลด์ ช่วง ขั้น และรายการ
cron expression กำหนดเวลางานที่เกิดซ้ำบนระบบ Unix-like syntax มาตรฐานมีห้าฟิลด์ที่คั่นด้วยช่องว่าง: นาที (0-59), ชั่วโมง (0-23), วันของเดือน (1-31), เดือน (1-12), วันของสัปดาห์ (0-7 โดยที่ 0 และ 7 ต่างหมายถึงวันอาทิตย์) เครื่องหมายดอกจัน (*) ในฟิลด์หมายถึง "ทุกค่าที่ถูกต้อง" expression 30 8 * * 1-5 ทำงานเวลา 08:30 ในวันจันทร์ถึงศุกร์ ช่วงใช้เครื่องหมายยัติภังค์: 1-5 ครอบคลุมค่า 1, 2, 3, 4, 5 รายการใช้เครื่องหมายจุลภาค: 1,15 หมายถึงวันที่ 1 และ 15 ขั้นใช้เครื่องหมายทับ: */15 ในฟิลด์นาทีหมายถึงทุก 15 นาที (0, 15, 30, 45) ตัวรวมเหล่านี้สามารถปรากฏร่วมกันได้: 0-30/10 หมายถึง 0, 10, 20, 30 สิ่งหนึ่งที่ cron ไม่มีคือฟิลด์เขตเวลา daemon อ่านนาฬิกาของเครื่องที่มันทำงานอยู่ ซึ่งตั้งค่าตามเขตเวลาท้องถิ่นของเซิร์ฟเวอร์ หากเซิร์ฟเวอร์ทำงานใน UTC แต่นักพัฒนาคาดหวังเวลาท้องถิ่น กำหนดการจะทำงานที่ชั่วโมงนาฬิกาที่ผิด กฎปฏิบัติคือถือว่า cron schedule เป็นนิพจน์เวลาท้องถิ่นของเซิร์ฟเวอร์ และบันทึกเขตเวลาของเซิร์ฟเวอร์ไว้คู่กับบรรทัด cron
ใช้ timestamp-converter ในเครื่อง
timestamp-converter บน Sunasty แปลงได้ทั้งสองทิศทาง: epoch เป็นวันที่ที่มนุษย์อ่านได้ และวันที่ที่มนุษย์อ่านได้กลับเป็น epoch คุณสามารถป้อนค่าความแม่นยำวินาทีหรือมิลลิวินาที เครื่องมือตรวจจับหน่วยจากขนาด เครื่องมือแสดงผลลัพธ์เป็น UTC และเวลาท้องถิ่นของอุปกรณ์คุณเองเคียงข้างกัน พร้อมค่าวินาทีและมิลลิวินาทีดิบที่พร้อมคัดลอก ปุ่ม Now จะกรอก timestamp ปัจจุบันให้ในคลิกเดียว ซึ่งเป็นวิธีที่รวดเร็วในการตรวจสอบ Unix time ปัจจุบันโดยไม่ต้องเปิด terminal ไม่มีตัวเลือกเขตเวลาแยกต่างหาก: คอลัมน์ท้องถิ่นจะสะท้อนเขตเวลาที่เบราว์เซอร์ของคุณตั้งไว้อยู่เสมอ ทั้งหมดนี้ทำงานในเบราว์เซอร์ ค่าที่คุณวางในฟิลด์ถูกอ่านโดย client-side JavaScript และไม่เคยออกจากอุปกรณ์
เครื่องมือที่กล่าวถึงในบทความนี้
- แปลง Timestampแปลง Unix epoch timestamp เป็นวันที่ที่อ่านได้ (UTC + เวลาท้องถิ่น) และกลับกัน ตรวจจับวินาทีหรือมิลลิวินาทีโดยอัตโนมัติ
- ความต่างของวันที่นับวัน สัปดาห์ เดือน และปีระหว่างสองวันที่, ทั้งหมดในเบราว์เซอร์ ไม่มีการอัปโหลด
- ตัวแปลง cron expressionแปลง cron expression และดูตัวอย่างเวลารันถัดไป ส่วนตัว ในเบราว์เซอร์
คำถามที่พบบ่อย
ทำไม JavaScript จึงใช้มิลลิวินาทีแทนวินาที?
Object Date ของ JavaScript ออกแบบมาให้ทำงานกับความแม่นยำต่ำกว่าวินาทีตั้งแต่เริ่มต้น และมิลลิวินาทีให้ความละเอียดมากกว่าวินาทีหนึ่งพันเท่าโดยไม่ต้องการจุดทศนิยม ข้อแลกเปลี่ยนคือค่าตัวเลขจะใหญ่กว่า ซึ่งเป็นเหตุที่ Date.now() ให้ตัวเลข 13 หลักในขณะที่ timestamps ฝั่งเซิร์ฟเวอร์ส่วนใหญ่เป็น 10 หลัก
เซิร์ฟเวอร์ทุกตัวที่รัน cron จำเป็นต้องใช้ UTC หรือไม่?
ไม่จำเป็น แต่การรันเซิร์ฟเวอร์บน UTC เป็นแนวปฏิบัติทั่วไปเพราะขจัดความคลุมเครือ เมื่อเซิร์ฟเวอร์อยู่ใน UTC cron expression อย่าง 0 2 * * * หมายถึง 02:00 UTC และเวลานั้นคงที่ตลอดทั้งปี บนเซิร์ฟเวอร์ใน zone ที่ใช้ DST งานเดียวกันจะทำงานที่ UTC instant ที่ต่างกันในฤดูร้อนและฤดูหนาว และอาจทำงานสองครั้งหรือข้ามครั้งหนึ่งที่ขอบเขตการเปลี่ยนนาฬิกา
ประเภทการเก็บข้อมูลที่ปลอดภัยสำหรับ timestamps หลังปี 2038 คืออะไร?
signed 64-bit integer เก็บ timestamps ความแม่นยำวินาทีได้ถึงปี 292277026596 ซึ่งเกินกว่าข้อกังวลในทางปฏิบัติใด ๆ ฐานข้อมูลปัจจุบันส่วนใหญ่เก็บ timestamps เป็นค่า 64-bit ตามค่าเริ่มต้น หากคุณกำลังทำงานกับ schema รุ่นเก่าหรือรูปแบบไฟล์ไบนารีที่ใช้ฟิลด์ 32-bit การย้ายไปยังพื้นที่เก็บข้อมูล 64-bit ก่อนขอบเขตปี 2038 คือวิธีแก้ที่ถูกต้อง