เครื่องมือสำหรับนักพัฒนา · ตัวแปลงการประทับเวลา Unix
การประทับเวลา Unix เชิงลบ: วันที่ก่อน 1970 จะแสดงอย่างไร
· มันทำงานอย่างไร
การประทับเวลา เวลายูนิกซ์ ข้อมูลรูปแบบ
เวลา Unix นับไปข้างหน้าจาก 1970 แต่ก็นับถอยหลังเช่นกัน โพสต์นี้อธิบายว่ายุคเชิงลบหมายถึงอะไร −1 กลายเป็นวินาทีสุดท้ายของ 1969 ได้อย่างไร และจุดที่ระบบที่ถือว่าค่าบวกพัง
วันเกิดที่มีเครื่องหมายลบ — ผู้ใช้ที่เกิดใน 1965 จัดเก็บเป็นจำนวนเต็มลบ และโค้ดที่ถือว่าเป็นข้อผิดพลาด
บันทึกของบุคคลที่เกิดก่อน 1970 สามารถมีการประทับเวลา Unix ที่เป็นลบได้อย่างถูกต้องตามกฎหมาย การปฏิเสธเครื่องหมายลบนำหน้าทุกตัวจะแปลงตัวเลือกการเป็นตัวแทนเป็นข้อผิดพลาดในการสูญเสียข้อมูล โปรแกรมแยกวิเคราะห์ของ ToolAcre ยอมรับเครื่องหมายเสริม และ `fromEpoch` ทำเครื่องหมายค่ามิลลิวินาทีที่แปลความหมายต่ำกว่าศูนย์เป็น `beforeEpoch` แทนที่จะถือว่าค่าดังกล่าวไม่ถูกต้อง
จากนั้นจอแสดงผลจะเพิ่มข้อความอธิบายว่า Instant นำหน้ายุค Unix สิ่งนี้ดีกว่าการแสดงวันที่โดยเงียบๆ เพราะมันทำให้ผู้ตรวจสอบมองเห็นสัญญาณที่ผิดปกติได้ หากสคีมาอัปสตรีมห้ามไม่ให้มีค่าเชิงลบ ความล้มเหลวจะเป็นของสคีมาหรือการย้ายข้อมูลนั้น ไม่ใช่ของเลขคณิตที่แมปนับทั้งสองด้านของศูนย์
จำนวนเต็มที่มีเครื่องหมายและยุค — เหตุใดจึงต้องลงนาม time_t และสิ่งที่ −1 และ −86400 สอดคล้องกับ
ศูนย์คือ 1970-01-01T00:00:00.000Z การทดสอบพื้นที่เก็บข้อมูลพิสูจน์ว่า −1 วินาทีคือช่วงเวลาก่อนหน้าทันที `1969-12-31T23:59:59.000Z` ในทำนองเดียวกัน −86,400 วินาทีคือหนึ่งวันคงที่ POSIX ก่อนศูนย์ เลขคณิตที่เซ็นชื่อจะทำให้แกนมีความต่อเนื่องแทนที่จะต้องใช้ยุคที่สองสำหรับบันทึกเก่า
โครงร่างระบุแหล่งที่มาของพื้นที่เก็บข้อมูลที่เซ็นชื่อเป็น `time_t` แต่โค้ดนี้ไม่ได้สร้างประวัติการออกแบบหรือประเภทที่ใช้โดยทุกแพลตฟอร์ม หลักฐานที่แคบกว่านั้นก็เพียงพอแล้ว: ตัวเลข JavaScript อาจเป็นค่าลบได้ การตรวจจับจะใช้ขนาดสัมบูรณ์ และวันที่สามารถจัดรูปแบบผลลัพธ์ได้ อธิบายประเภทที่ประกาศของฟิลด์การผลิตแยกจากอินพุตที่ยอมรับของตัวแปลง
เลขคณิตยุคที่ลงนามรอบศูนย์ โดยไม่อ้างว่าเหตุใด every time_t จึงเลือกประเภทของมัน
ค่าลบยังคงรักษาความแตกต่างของหน่วยเช่นเดียวกับค่าบวก `−1000` วินาทีชี้ 1,000 วินาทีก่อนยุค ในขณะที่ `−1000` มิลลิวินาทีชี้ก่อนหน้ายุคนั้นเพียงหนึ่งวินาที การตรวจจับอัตโนมัติจะถือว่าทั้งสองเป็นวินาทีเนื่องจากมีขนาดต่ำกว่า 10¹¹ ดังนั้นการนับมิลลิวินาทีก่อนยุคสั้นๆ จึงต้องเลือกมิลลิวินาทีอย่างชัดเจน
นี่เป็นความล้มเหลวอย่างเป็นรูปธรรมของนิทานพื้นบ้านเรื่องการนับเลข นักพัฒนาซอฟต์แวร์ที่เห็นเครื่องหมายลบและตัวเลขสี่หลักไม่สามารถอนุมานลักษณะที่ปรากฏของหน่วยได้ ใช้สัญญาต้นทาง เลือกตัวเลือก และตรวจสอบบันทึกหน่วย กฎขนาดของ ToolAcre เป็นค่าเริ่มต้นสำหรับข้อมูลทั่วไป ไม่ใช่การแทนที่ข้อมูลเมตาในค่าประวัติที่ใกล้เคียงกับ 1970
เมื่อค่าลบล้มเหลว — ระบบที่ใช้ 1 เป็นผู้พิทักษ์ พื้นที่เก็บข้อมูลที่ไม่ได้ลงนาม เครื่องมือเลือกวันที่ที่ยึด และภาษาที่ปฏิเสธ
ภายนอกตัวแปลง บางครั้ง `−1` จะถูกสงวนไว้เป็น Sentinel ที่ขาดหายไป และคอลัมน์ที่ไม่ได้ลงนามจะไม่สามารถรักษาช่วงเวลาเชิงลบใดๆ ได้ นี่เป็นความเป็นไปได้ในการออกแบบทั่วไป แต่พื้นที่เก็บข้อมูลไม่สามารถรับรองได้ว่าฐานข้อมูล ตัวเลือกวันที่ หรือภาษาใดทำงานอย่างไร ทดสอบขอบเขตจริงก่อนที่จะย้ายวันที่เก็บถาวรผ่านขอบเขตนั้น
การสอบสวนที่มีประโยชน์ประกอบด้วยค่าสามค่า: null หรือเครื่องหมายหายไปที่บันทึกไว้ −1 และวันที่เก่ากว่าอย่างชัดเจน หาก −1 หายไปในขณะที่ค่าเก่ายังคงอยู่ การจัดการกับ Sentinel จะเกี่ยวข้อง หากผลเชิงลบทั้งหมดล้มเหลว ให้ตรวจสอบประเภทและการตรวจสอบความถูกต้อง อย่า "แก้ไข" อาการโดยการเพิ่ม 1970 ปี หรือใช้ค่าสัมบูรณ์ เนื่องจากทั้งสองสร้าง Instant ที่แตกต่างกัน
ตัวอย่างการทำงาน: การแปลง 14182940 — เลขคณิตเป็นวันที่ 1969 กรกฎาคมใน UTC และในโซนท้องถิ่นทางตะวันตกของ Greenwich
เป็นเวลา −14,182,940 วินาที ให้เริ่มต้นที่ยุคและย้อนกลับ 164 ครบ 86,400 วินาที โดยเหลือ 13,340 วินาที ส่วนที่เหลือคือ 3 ชั่วโมง 42 นาที และ 20 วินาที ผลลัพธ์ของการอ่าน UTC คือ `1969-07-20T20:17:40.000Z` ซึ่งเป็นการเลือกทันทีที่นี่สำหรับบทความนี้โดยเฉพาะ
การอ่านค่าท้องถิ่นทางตะวันตกของ UTC อาจแสดงชั่วโมงนาฬิกาแขวนก่อนหน้า หรือแม้แต่วันที่อื่น แต่ผลลัพธ์ที่แน่นอนขึ้นอยู่กับโซนเบราว์เซอร์และกฎนานาชาติ อ่านจากแผงแทนที่จะเผยแพร่คำตอบที่เป็นสากล การยืนยันแบบคงที่คือแถว ISO แถวท้องถิ่นเป็นคำอธิบายประกอบด้านสิ่งแวดล้อมสำหรับจำนวนลบเดียวกันนั้น
ตัวอย่างการทำงาน: การแปลง −14,182,940 ด้วย UTC เลขคณิตที่ตรวจสอบได้
ToolAcre ตรวจสอบค่าที่ตีความกับ ±8.64×10¹⁵ มิลลิวินาที ซึ่งเป็นช่วงวันที่ที่ระบุไว้ในแหล่งที่มา นอกจากนี้ยังพิสูจน์การแปลงจาก −2,208,988,800 วินาทีเป็น `1900-01-01T00:00:00.000Z` ข้อเท็จจริงเหล่านี้แสดงให้เห็นว่าเส้นทางไปถึงก่อน 1970 ได้ดี โดยไม่บอกเป็นนัยว่าระบบจัดเก็บข้อมูลทุกระบบสามารถรองรับช่วงเดียวกันได้
ฟิลด์ 32 บิตที่ลงนามมีช่วงเวลาทางคณิตศาสตร์ที่แคบกว่าวันที่ JavaScript แต่ตัวแปลงจะไม่ตรวจสอบความกว้างของฟิลด์เมื่อคุณวางตัวเลข รักษาประเภทแหล่งที่มาไว้ในการตรวจสอบ การแปลงเบราว์เซอร์ที่ประสบความสำเร็จแสดงให้เห็นถึงความสามารถในการนำเสนอที่นี่ ไม่ใช่การสลับกลับอย่างปลอดภัยผ่านเฟิร์มแวร์ คอลัมน์ SQL หรือโปรโตคอลไบนารี่ที่อื่น
ทราบช่วงวันที่ของตัวแปลง ขีดจำกัด 32 บิตภายนอกขึ้นอยู่กับประเภทการจัดเก็บข้อมูล
การเปลี่ยนการนับเป็น JavaScript วันที่ไม่ได้สร้างปฏิทินพลเรือนที่พิมพ์จริงในทุกสถานที่เมื่อหลายศตวรรษก่อนขึ้นมาใหม่ การใช้งานใช้รูปแบบวันที่ของแพลตฟอร์มและส่งคืนการเป็นตัวแทน ISO ไม่มีตัวเลือกปฏิทินในอดีต ไฟล์เก็บถาวรสถานที่ หรือแหล่งสารคดีสำหรับการปฏิรูปปฏิทิน การเรียกร้องเหล่านั้นขาดไปโดยเจตนา
สำหรับบันทึกซอฟต์แวร์สมัยใหม่ การแสดงเครื่องจักรที่มีประสิทธิภาพอาจยังคงเป็นสัญญาที่คุณต้องการ สำหรับลำดับวงศ์ตระกูล ประวัติทางกฎหมาย หรือการถอดความเอกสารสำคัญ ให้คงวันที่เขียนต้นฉบับและบริบทของปฏิทินควบคู่ไปกับยุคสมัยใดๆ ที่ได้รับมา หมายเลขที่จัดเรียงได้สะดวกไม่ควรลบความไม่แน่นอนที่การแปลงไม่สามารถแก้ไขได้
การอ้างประวัติปฏิทินอยู่นอกเหนือหลักฐานของผู้แปลงรายนี้
ค่าลบคือทิศทางบนแกนยุค ไม่ใช่หมวดหมู่ข้อผิดพลาด ToolAcre แยกวิเคราะห์ ใช้กฎวินาทีหรือมิลลิวินาทีเดียวกันตามขนาด และตั้งค่าสถานะผลลัพธ์เหมือนก่อนยุค พฤติกรรมดังกล่าวช่วยให้ผู้ตรวจสอบแยกแยะ Instant เก่าที่ถูกต้องตามกฎหมายจาก Sentinel หรือความล้มเหลวของพื้นที่จัดเก็บที่ไม่ได้ลงนามในที่อื่น
เมื่อตรวจสอบข้อมูล pre-1970 ให้ระบุหน่วย ประเภทแหล่งที่มา และแบบแผนค่าที่หายไป ก่อนที่จะตีความเครื่องหมาย จากนั้นเปรียบเทียบผลลัพธ์ ISO กับบันทึกที่รู้จัก เครื่องหมายเพียงอย่างเดียวถือเป็นเลขคณิตที่มีความหมาย สคีมาโดยรอบจะกำหนดว่าผู้ผลิตตั้งใจให้เลขคณิตนั้นหรือใช้ตัวเลขเดียวกันกับค่าควบคุม