เครื่องมือสำหรับนักพัฒนา · ตัวแปลงการประทับเวลา Unix
ISO 8601 กับ RFC 3339: รูปแบบวันที่สองรูปแบบที่อยู่เบื้องหลังการตอบกลับ API ของคุณ
· พื้นหลัง
การประทับเวลา ISO-8601 API
API ส่วนใหญ่อ้างว่าใช้ ISO 8601 และใช้งานจริง RFC 3339 ซึ่งเป็นโปรไฟล์ที่เข้มงวดมากขึ้นซึ่งออกแบบมาเพื่ออินเทอร์เน็ต โพสต์นี้จะอธิบายเอกสารทั้งสอง ความแตกต่าง และความเกี่ยวข้องกับจำนวนเต็มของยุค
ช่อง 'ISO 8601' ที่ปฏิเสธ ISO 8601 ที่ถูกต้อง — วันที่ของสัปดาห์หรือค่าความแม่นยำลดลงที่ส่งไปยัง API ที่คาดหวัง RFC 3339
ฟิลด์ API ที่อธิบายแบบไม่เป็นทางการว่า “ISO 8601” อาจยอมรับรูปร่างวันที่-เวลาเพียงรูปแบบเดียวเท่านั้น การส่งการนำเสนอที่ถูกต้องตามมาตรฐานอื่นยังคงสามารถล้มเหลวในการแยกวิเคราะห์ได้ วิธีแก้ไขคือไม่ต้องโต้แย้งจากชื่อร่ม มันคือการบันทึกไวยากรณ์ลวดที่แน่นอนพร้อมตัวอย่างและการทดสอบการตรวจสอบความถูกต้อง
ToolAcre สนับสนุนเอาต์พุตตามรูปแบบบัญญัติที่เสถียรจาก `Date.toISOString()` แต่ไม่ใช่ชุดความสอดคล้องสำหรับการนำเสนอทุกครั้ง ถือว่าสตริงที่สร้างขึ้นเป็นรูปแบบการแลกเปลี่ยนที่มีประโยชน์รูปแบบหนึ่ง และเปรียบเทียบกับสัญญา API ที่คุณเป็นเจ้าของจริง
สคีมาจึงควรเผยแพร่นิพจน์ทั่วไปหรือประเภทที่เป็นทางการก็ต่อเมื่อสะท้อนถึง parser อย่างถูกต้องเท่านั้น ตัวอย่างเพียงอย่างเดียวก็มีประโยชน์ แต่กรณีการปฏิเสธที่ชัดเจนปิดความกำกวม
มาตรฐานวันที่แบบกว้างและไวยากรณ์ API แบบแคบไม่สามารถใช้แทนกันได้
แบบฟอร์มที่สร้างขึ้นประกอบด้วยวันที่ในปฏิทิน `T` เวลาเป็นมิลลิวินาทีและต่อท้าย Z การใช้งานจะเรียกสิ่งนี้ว่า ISO 8601 (UTC) ใน UI อินพุตยอมรับสิ่งที่ JavaScript อ่านวันที่ รวมถึงการชดเชยที่ชัดเจนและรูปร่างวันที่-เวลาแบบไม่มีโซนของตัวเลือกในเครื่อง
ลักษณะการทำงานนั้นแคบกว่าตัวแยกวิเคราะห์มาตรฐานที่สมบูรณ์มาก วันที่ของสัปดาห์ ช่วงเวลา ระยะเวลา และความแม่นยำที่ลดลงไม่มีการทดสอบพื้นที่เก็บข้อมูล สตริงที่ยอมรับโดยเบราว์เซอร์หนึ่ง วันที่ จึงไม่รับประกันในภาษาต่างๆ และแบบฟอร์มพิเศษที่ถูกปฏิเสธไม่ได้พิสูจน์หักล้างจุดยืนของสตริงที่อื่น
ความแม่นยำระดับมิลลิวินาทีคงที่ของเอาต์พุตเป็นทางเลือกในการจัดรูปแบบ ไม่ใช่หลักฐานที่แสดงว่าแหล่งที่มาวัดค่าเป็นมิลลิวินาที วันที่อาจได้รับค่าเต็มวินาทีและยังคงพิมพ์ `.000`
ToolAcre ปล่อยรูปแบบ ISO หนึ่งรูปแบบ มันไม่ได้ตรวจสอบมาตรฐาน ISO 8601 แบบเต็ม
สมุดงานมีลักษณะเฉพาะ RFC 3339 ปีและกฎออฟเซ็ตบังคับ ไม่มีข้อความ RFC หรือ parser เฉพาะอยู่ในชุดแหล่งที่มา ดังนั้นจึงไม่มีการยืนยันรายละเอียดเหล่านั้น สัญญาการเขียนกำหนดให้ละเว้นความแม่นยำที่ไม่ได้รับการสนับสนุน แทนที่จะอ้างอิงชื่อเรื่องจากหน่วยความจำ
หาก API ของคุณหมายถึง RFC 3339 ให้ตั้งชื่อไว้ในสคีมาและทดสอบกับการใช้งานที่มีพื้นฐานอยู่ในข้อกำหนดจริง ToolAcre สามารถเชื่อมโยงยุคที่รู้จักกับเอาต์พุต UTC ISO เพื่อการเปรียบเทียบ แต่ไม่สามารถรับรองได้ว่าอินพุตที่กำหนดเองเป็นไปตามโปรไฟล์นั้น
นี่คือการป้องกันด้านบรรณาธิการและวิศวกรรม: โปรไฟล์มาตรฐานเป็นสัญญาที่แม่นยำ และการถอดความโดยไม่มีข้อความอาจเสี่ยงต่อการเปลี่ยนแปลงข้อกำหนดในเอกสาร
RFC 3339 ข้อกำหนดจำเป็นต้องมีแหล่งมาตรฐานภายนอกที่ไม่มีอยู่ในที่เก็บนี้
การอ้างสิทธิ์เกี่ยวกับตัวคั่นสำรอง ตัวระบุตัวพิมพ์เล็ก และ `−00:00` ขึ้นอยู่กับภาษามาตรฐานที่แน่นอน พวกเขาจะถูกละไว้ที่นี่ เครื่องตรวจจับโซนของตัวแปลงจะจดจำ Z ต่อท้ายหรือตัวเลข `±HH:MM` และตั้งค่าสถานะวันที่-เวลาแบบไม่มีโซนเป็นแบบท้องถิ่น นั่นคือขอบเขตที่เราสามารถตรวจสอบได้
สร้างการตรวจสอบความถูกต้อง API จากตัวอย่างที่ได้รับการยอมรับอย่างชัดเจนและกรณีการปฏิเสธ อย่าอนุมานการอนุญาตจาก JavaScript ตัวแยกวิเคราะห์ความสะดวกสบายของ Date เบราว์เซอร์ที่อนุญาตสามารถปรับอินพุตให้เป็นมาตรฐานซึ่งเซิร์ฟเวอร์ที่เข้มงวดปฏิเสธอย่างถูกต้อง โดยซ่อนข้อบกพร่องด้านความสามารถในการทำงานร่วมกันระหว่างการทดสอบด้วยตนเอง
parser ที่คำนึงถึงมาตรฐานโดยเฉพาะควรส่งคืนเหตุผลข้อผิดพลาดที่มีโครงสร้าง การปล่อยให้วันที่ทำให้อินพุตแบบกว้างเป็นมาตรฐานสามารถเปลี่ยนข้อผิดพลาดในการตรวจสอบความถูกต้อง API ให้เป็นความคลาดเคลื่อนข้ามแพลตฟอร์มในภายหลังได้
ตัวคั่นเฉพาะและกฎออฟเซ็ตที่ไม่รู้จักจะถูกละเว้นโดยไม่มีข้อความมาตรฐาน
ค่ายุคทำให้เลขคณิตและการเรียงลำดับมีขนาดกะทัดรัดเมื่อหน่วยและจุดกำเนิดได้รับการแก้ไข วันที่-เวลาที่เป็นข้อความทำให้ UTC หรือการอ่านค่าชดเชยปรากฏแก่ผู้คน และคงตัวกำหนดนั้นไว้ระหว่างทาง API จำนวนมากเลือกสตริงตามรูปแบบบัญญัติหนึ่งสตริงเพื่อหลีกเลี่ยงความคลุมเครือของจำนวนเต็ม JavaScript หรือหน่วย
หาก API มีทั้งสองอย่าง ให้กำหนดว่าฟิลด์ใดเป็นข้อตกลงที่เชื่อถือได้และทดสอบ สตริงที่จัดรูปแบบเก่าๆ ข้างยุคใหม่นั้นแย่กว่าสตริงเดี่ยวๆ ToolAcre สามารถเปรียบเทียบทั้งคู่ได้โดยการแปลงจำนวนเต็มและตรวจสอบค่า ISO ที่สร้างขึ้น แต่การบังคับใช้ความสอดคล้องเป็นของผู้ผลิต
ตัวอย่างการทำงาน: หนึ่งครั้ง การนำเสนอสี่รายการ — epoch วินาที, epoch มิลลิวินาที, สตริง RFC 3339 ใน UTC และอีกหนึ่งรายการที่มีออฟเซ็ตในเครื่อง
ใช้ `2025-02-03T10:22:00.000Z` ทันที รูปแบบยุคของมันคือ 1,738,578,120 วินาที และ 1,738,578,120,000 มิลลิวินาที การอ่านค่าออฟเซ็ตที่ชัดเจนคือ `2025-02-03T12:22:00+02:00`; การแยกวิเคราะห์ใน ToolAcre จะส่งกลับยุคเดียวกันและเป็นที่ยอมรับ UTC ISO แถว
การแสดงเหล่านี้คือการแสดงที่ตรวจสอบได้ที่เก็บข้อมูลสี่รายการ: วินาที, มิลลิวินาที, เอาต์พุต toISOString และสตริงออฟเซ็ตตัวเลขที่แยกวิเคราะห์วันที่ ตัวอย่างไม่ได้อ้างว่า parser ภายนอกทุกตัวยอมรับความแม่นยำเศษส่วนหรือไวยากรณ์ออฟเซ็ตเดียวกัน ดำเนินการตรวจสอบความถูกต้องของ API ก่อนจัดส่ง
การลบออฟเซ็ต +02:00 ออกจากนาฬิกาที่เขียน จะได้ 10:22 UTC ความเท่าเทียมกันแบบง่ายๆ นั้นเพียงพอที่จะทดสอบอินพุตเฉพาะนี้โดยไม่ต้องสรุปไวยากรณ์มาตรฐานแบบเต็ม
ตัวอย่างการทำงาน: ทันทีหนึ่งในสี่รูปแบบที่เก็บข้อมูลนี้สามารถตรวจสอบได้
HTTP ส่วนหัวและวันที่ของอีเมลใช้สัญญาที่เป็นข้อความซึ่งไม่ได้นำมาใช้ที่นี่ ToolAcre ไม่ได้จัดรูปแบบโปรโตคอลเหล่านั้น และไม่ได้สัญญาว่าจะสามารถทดแทนเอาต์พุต ISO ได้ การประทับเวลาทันทีสามารถเหมือนกันได้ในขณะที่การแสดงเส้นลวดที่ต้องการนั้นแตกต่างกัน
เก็บการซีเรียลไลซ์โปรโตคอลไว้ในอะแดปเตอร์เฉพาะโดยคัดลอกฟิกซ์เจอร์จากข้อกำหนดที่เชื่อถือได้ ใช้การแปลงยุคเพื่อตรวจสอบ Instant ที่สำคัญ จากนั้นทดสอบไวยากรณ์แยกกัน การทำเช่นนี้จะป้องกันไม่ให้ค่าที่ถูกต้องของปฏิทินผ่านการตรวจทานในซองจดหมายที่ไม่ถูกต้องทางวากยสัมพันธ์
อะแดปเตอร์เฉพาะควรรักษาไว้ว่าออฟเซ็ตที่หายไปหรือไม่รู้จักมีความหมายโดเมนหรือไม่ การทำให้วันที่ที่เป็นต้นฉบับทั้งหมดเป็นข้อสันนิษฐานในท้องถิ่นสามารถทำลายข้อมูลนั้นได้
โปรโตคอลข้อความอื่นๆ ยังคงอยู่นอกตัวแปลง
ระบุรูปแบบแคบที่ API ของคุณยอมรับ แทนที่จะใช้ป้ายกำกับแบบกว้างๆ สำหรับเครื่องมือนี้ เอาต์พุตที่สามารถทำซ้ำได้ที่ปลอดภัยที่สุดคือสตริง UTC ISO ที่ส่งคืนโดย `toISOString()` และอินพุตตัวเลขที่ปลอดภัยที่สุดจะมีสัญญาวินาทีหรือมิลลิวินาทีที่ชัดเจน
ToolAcre เชื่อมโยงแบบฟอร์มเหล่านั้นและรายงานสมมติฐาน ไม่ได้ตัดสินกรณีขอบของ ISO 8601 หรือ RFC 3339 ทั้งหมด การเป็นเจ้าของไวยากรณ์ หน่วย และโซนที่ชัดเจนคือสิ่งที่ทำให้การประทับเวลาพกพาได้ โดยไม่ต้องแนบชื่อมาตรฐานที่คุ้นเคยลงในฟิลด์ที่ไม่ระบุ
สัญญาที่ชัดเจนช่วยให้ลูกค้าล้มเหลวก่อนเวลาด้วยข้อความที่เป็นประโยชน์ ป้ายกำกับกว้างๆ จะผลักดันความขัดแย้งเข้าสู่รันไทม์ โดยที่ผู้แยกวิเคราะห์ที่ถูกต้องสองคนจะสามารถเลือกชุดย่อยที่แตกต่างกันได้