เปรียบเทียบ RFC 3339 กับ ISO 8601

 (ijmacd.github.io)
3 คะแนน โดย GN⁺ 2023-09-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เมื่อต้องจัดการการเขียนวันที่·เวลา RFC 3339 ใกล้เคียงกับชุดย่อยที่แคบและใช้งานได้ง่ายสำหรับเว็บ·อินเทอร์เน็ต ขณะที่ ISO 8601-1:2019 ครอบคลุมชุดรูปแบบที่กว้างกว่ามาก
  • ขอบเขตการเปรียบเทียบจำกัดอยู่ที่ ISO 8601-1:2019 และนิพจน์เพิ่มเติมใน ISO 8601-2:2019 เช่น ฤดูกาล เซต ตัวบ่งชี้ความไม่แน่นอน และเลขคณิตวันที่ ยังไม่ถูกรวมไว้ในตาราง
  • มาตรฐานทั้งสองรองรับ รูปแบบวันที่·เวลาพื้นฐาน ที่ใช้กันอย่างแพร่หลายร่วมกัน เช่น 2026-06-26, 14:08:00Z, 2026-06-26T14:08:00Z, และออฟเซ็ต +00:00
  • ISO 8601 ครอบคลุมถึงศตวรรษ ทศวรรษ วันลำดับ วันที่แบบสัปดาห์ เวลาแบบย่อ เครื่องหมายจุลภาคทศนิยม ช่วงเวลา(P1Y) และช่วง(2026-06-26/P1Y) แต่ในตาราง RFC 3339 ไม่รองรับส่วนใหญ่
  • สำหรับการเขียน Date-Time ความต่างเรื่อง ตัวคั่น T ตัวพิมพ์ใหญ่·เล็ก และออฟเซ็ตอย่าง -00:00 เป็นจุดที่กำหนดความเข้ากันได้ของ parser ในทางปฏิบัติ

ขอบเขตการเปรียบเทียบและข้อสมมติ

  • ตารางรูปแบบ ไม่ใช่รายการที่ครบถ้วนสมบูรณ์
  • มาตรฐานที่ใช้เป็นเกณฑ์คือ ISO 8601-1:2019
    • ฉบับก่อนหน้าและร่างมีความแตกต่างที่สำคัญ
  • ISO 8601-2:2019 มีนิพจน์เพิ่มเติม แต่หน้านี้ยังไม่ได้นำมารวม
    • กลุ่มย่อยต่ำกว่าระดับปี เช่น ฤดูกาล
    • หน่วยการจัดกลุ่ม
    • เซต
    • ตัวบ่งชี้ความไม่แน่นอน
    • เลขคณิตวันที่
  • RFC 3339 เสนอว่ามาตรฐานย่อยสามารถแทนที่ T ด้วยอักขระอื่นได้ แต่ยกตัวอย่างไว้เพียง อักขระช่องว่าง เท่านั้น
  • แต่ละมาตรฐานกำหนดรูปแบบตามวัตถุประสงค์การใช้งาน และรูปแบบอื่นนอกเหนือจากนั้นไม่แนะนำ

ISO 8601 ครอบคลุมการเขียนวันที่กว้างกว่า

  • ทั้ง RFC 3339 และ ISO 8601 รองรับ วันที่แบบปี-เดือน-วัน เช่น 2026-06-26
  • ISO 8601 รองรับการแสดงวันที่ได้หลากหลายกว่า RFC 3339
    • ศตวรรษ: 20
    • ทศวรรษ: 202
    • ปี: 2026
    • ปี-เดือน: 2026-06
    • วันลำดับ: 2026-177
    • วันที่แบบสัปดาห์: 2026-W26, 2026-W26-5
    • รูปแบบพื้นฐาน: 20260626, 2026177, 2026W26, 2026W265
  • ในตาราง RFC 3339 ไม่อนุญาตรูปแบบวันที่เฉพาะของ ISO ข้างต้น

ความต่างของการเขียนเวลา

  • มาตรฐานทั้งสองอนุญาต เวลาในระดับวินาทีและออฟเซ็ตเขตเวลา ร่วมกัน เช่น 14:08:00Z, 14:08:00+00:00, 14:08:00.372+00:00
  • RFC 3339 ไม่แยกตัวพิมพ์ใหญ่·เล็ก จึงสามารถใช้ t, z แทน T, Z ได้
    • ISO 8601 ฉบับก่อนหน้าก็ไม่แยกตัวพิมพ์ใหญ่·เล็กเช่นกัน
  • ISO 8601 สามารถใส่ ส่วนทศนิยม ให้กับค่าหน่วยเวลาที่เล็กที่สุดได้
    • ในตารางมักยกตัวอย่างเป็นทศนิยมหนึ่งตำแหน่ง แต่ตัวมาตรฐานอนุญาตความละเอียดได้ตามต้องการ
    • อนุญาตทั้งเครื่องหมายจุลภาคและจุดเป็นตัวคั่นทศนิยม และใช้แทนกันได้ในทุกรูปแบบ
  • ISO 8601-1:2019 อนุญาตให้ละ T ได้ในการแสดง เวลาเดี่ยว ๆ หากไม่กำกวม
  • ISO 8601 รองรับการเขียนเวลาแบบย่อ แบบพื้นฐาน และแบบจุลภาคทศนิยม เช่น 14, 14:08, 14:08:00, 140800, T14:08:00, 14:08:00,372
  • RFC 3339 อนุญาต ออฟเซ็ต -00:00 เช่น 14:08:00-00:00 แต่ในตาราง ISO 8601 ไม่อนุญาต

T และตัวคั่นใน Date-Time

  • ทั้ง RFC 3339 และ ISO 8601 อนุญาต Date-Time เช่น 2026-06-26T14:08:00Z และ 2026-06-26T14:08:00+00:00
  • ใน การแสดง Date-Time ของ ISO 8601 ต้องมี T เสมอ
    • ฉบับก่อนหน้าอนุญาตให้ละ T ใน Date-Time ได้
    • แม้ในฉบับก่อนหน้าก็ไม่อนุญาตให้แทรกอักขระทดแทน เช่น ช่องว่างหรือขีดล่าง
  • ในตาราง RFC 3339 อนุญาตรูปแบบย่อยของ Date-Time ดังต่อไปนี้
    • t และ z ตัวพิมพ์เล็ก: 2026-06-26t14:08:00z
    • ตัวคั่นเป็นช่องว่าง: 2026-06-26 14:08:00Z
    • ตัวคั่นเป็นขีดล่าง: 2026-06-26_14:08:00Z
    • ออฟเซ็ต -00:00: 2026-06-26T14:08:00-00:00
  • ISO 8601 รองรับ Date-Time แบบย่อ รวมถึง Date-Time ที่อิงวันลำดับและวันที่แบบสัปดาห์ เช่น 2026-06-26T14, 2026-06-26T14:08, 2026-06-26T14:08:00, 2026-177T14:08, 2026-W26-5T14:08

ระยะเวลาและช่วงเป็นฝั่ง ISO 8601 เป็นหลัก

  • ในตาราง รูปแบบ ระยะเวลา (Periods) ถูกทำเครื่องหมายไว้เฉพาะ ISO 8601
    • ตัวอย่าง: P1Y, P1M, P1W, P1D
    • ตัวอย่างที่มีเวลา: PT1H, PT1M, PT1S
    • ตัวอย่างแบบผสม: P1Y1M1DT1H1M1S
    • ตัวอย่างทศนิยม: P1.5Y, P1,5W, PT1.5S
  • รูปแบบ ช่วง (Ranges) ก็ถูกทำเครื่องหมายไว้เฉพาะ ISO 8601 เช่นกัน
    • วันที่และระยะเวลา: 2026-06-26/P1Y
    • วันที่และวันที่: 2026-06-26/2026-06-26
    • ระยะเวลาและวันที่: P1Y/2026-06-26
    • Date-Time และระยะเวลา: 2026-06-26T14:08/P1DT1H
    • ช่วงแบบทำซ้ำ: R/2026-06-26/P1Y, R10/2026-06-26/P1Y

คีย์รูปแบบและเครื่องมือทดสอบ

  • ตารางรูปแบบใช้ คีย์รูปแบบ เช่น %Y, %M, %D, %h, %m, %s
    • %Y: Year
    • %M: Month
    • %D: Day
    • %V: Week Year
    • %W: Week
    • %w: Week Day
    • %O: Ordinal Day
    • %h: Hour
    • %m: Minute
    • %s: Second
    • %u: Microsecond
    • %n: Nanosecond
    • %Z: ชั่วโมงของเขตเวลา พร้อม + หรือ -
    • %z: นาทีของเขตเวลา
  • ตัวตรวจสอบรูปแบบจะตรวจเพียงว่าอินพุตตรงกับรูปแบบใดรูปแบบหนึ่งในตารางหรือไม่
    • ไม่ได้ตรวจสอบรูปแบบที่เป็นไปได้ทั้งหมด
  • ISO 8601 as a Service เป็นบริการสำหรับการทดสอบเบตา
    • ปัจจุบันรองรับเฉพาะ Date, Time, DateTime
    • ยังไม่รองรับ Period และ Range
  • ซอร์สโค้ดเผยแพร่บน GitHub

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-09-01
ความคิดเห็นบน Hacker News

  • น่าแปลกที่ไม่มีวิธีกำหนด วันที่/เวลาในอนาคต โดยอิงตามเขตเวลาหนึ่ง ๆ ตัวอย่างเช่น อาจอยากนัดประชุมวันที่ 1 กรกฎาคม 2030 เวลา 18:00 น. ตามเวลาท้องถิ่นลอนดอน ซึ่งไม่ว่ากฎเขตเวลาของสหราชอาณาจักรจะเปลี่ยนไปอย่างไรในระหว่างนั้น ก็ต้องยังคงเป็น “18:00 น. ของลอนดอน”
    ปัจจุบันสหราชอาณาจักรใช้ประมาณ Z+00:00 ในช่วงพฤศจิกายนถึงมีนาคม และใช้เวลาออมแสง Z+01:00 ในช่วงเมษายนถึงตุลาคม[0] แต่ก่อนถึงปี 2030 ก็อาจรับ Central European Time[1] มาใช้ ลองใช้ British Double Summer Time[2] อีกครั้ง หรือยกเลิกเวลาออมแสงก็ได้ ดังนั้น “18:00 น.” เวลาเดียวกันนี้อาจแตกต่างกันมากเมื่ออิงกับ epoch หนึ่ง ๆ
    อยากใส่ “18:00 น. ตามเวลาลอนดอน ณ ตอนนั้น” ลงในอีเวนต์ปฏิทิน แต่ไม่มีวิธีแสดง 2030-07-01 18:00:00 Europe/London ในรูปแบบมาตรฐานที่ทำงานร่วมกันได้
    [0] https://en.wikipedia.org/wiki/British_Summer_Time
    [1] https://en.wikipedia.org/wiki/Central_European_Time
    [2] https://en.wikipedia.org/wiki/British_Summer_Time#Periods_of...

    • มีเอกสารร่างสำหรับรูปแบบแบบนั้นชื่อ IXDTF (Internet Extended Date/Time Format)[0] สามารถต่อเขตเวลาเป็นชื่อ tz ไว้ในวงเล็บเหลี่ยมหลังสตริง RFC 3339 ได้ และถ้าต้องการแสดงเวลาท้องถิ่น ก็ต้องใส่ค่าประมาณของ UTC offset ไปด้วย
      ตัวอย่างเช่น 2030-07-01 18:00:00 Europe/London จะกลายเป็น 2030-07-01T18:00:00+01:00[Europe/London] หากกฎของสหราชอาณาจักรเปลี่ยนไปก่อนหน้านั้น timestamp นี้จะกลายเป็น “ไม่สอดคล้องกัน” และให้แอปพลิเคชันตัดสินใจว่าจะจัดการอย่างไร อย่างไรก็ตาม หากใส่ ! หน้าชื่อเขตเวลาในวงเล็บเหลี่ยม ระบบต้องตรวจจับปัญหา แทนที่จะทำตาม UTC offset แบบหลับหูหลับตา
      รูปแบบ timestamp แบบขยายนี้ยังใช้ในไลบรารี Temporal ที่เสนอสำหรับ JavaScript[1] ด้วย และฟังก์ชันพาร์ส ZonedDateTime.from()[2] ให้ควบคุมผ่านตัวเลือก offset ได้ว่าจะให้ฝั่งใดมีความสำคัญกว่าเมื่อเจอ timestamp ที่ไม่สอดคล้องกัน นอกจากนี้ยังรองรับการละ UTC offset แล้วระบุเฉพาะเขตเวลา แต่เตือนว่าช่วงเวลาหนึ่งชั่วโมงที่เกิดซ้ำตอนเปลี่ยนเวลาออมแสงจะกำกวม
      [0] https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...
      [1] https://tc39.es/proposal-temporal/docs/strings.html#iana-tim...
      [2] https://tc39.es/proposal-temporal/docs/ambiguity.html#ambigu...
    • จริง ๆ แล้วดูเหมือนต้องการข้อมูลที่เฉพาะเจาะจงกว่าเขตเวลา เช่น สมมติว่าอยากพบกันที่กลาสโกว์ สกอตแลนด์ ไม่ใช่ลอนดอน ในวันที่ 1 กรกฎาคม 2030 เวลา 18:00 น. ตอนนี้กลาสโกว์อยู่ในเขตเวลา Europe/London
      แต่ก็ไม่ใช่เรื่องเป็นไปไม่ได้ที่จะจินตนาการว่าระหว่างนั้นสกอตแลนด์อาจจัดประชามติเอกราชอีกครั้ง แล้วเข้าร่วม Central European Time หรือสร้าง Scottish Standard Time ขึ้นมา
    • กับดักของการแสดงแบบนี้คือจะเกิด timestamp ที่กำกวมหรือเป็นไปไม่ได้ 2023-11-05 01:30:00 America/New_York จะเป็นหนึ่งในสองเวลาที่ต่างกัน
      ในปฏิทิน ความหมายที่ต้องการส่วนใหญ่คือ “เวลาเดียวกันตามนาฬิกาบนผนัง” จึงสมเหตุสมผล แต่มีความยากด้าน UI ในการจัดการเวลาประหลาด ๆ และอาจอยากใส่วิธีแก้ความกำกวมไว้ในไวยากรณ์ด้วย โชคดีที่ปกติการเปลี่ยนเวลาแบบนี้มักเกิดตอนกลางดึก แต่เคยเห็นเรื่องแบบนี้ในงานจริงมาแล้ว
      หากเชิญคนที่อยู่ในเขตเวลาที่ไม่มีเวลาออมแสง เวลาในปฏิทินของคนนั้นจะสั่นไหว และบางครั้งเพื่อนร่วมงานต่างประเทศก็ต้องยอมรับเรื่องนี้
    • ในโลกปฏิทิน iCal รองรับอยู่แล้ว วันที่-เวลาที่ไม่มีเขตเวลาหมายถึงเวลาท้องถิ่นเท่านั้น[0]
      [0]: https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5
    • ข้อมูลที่ต้องมีคือสามอย่าง: วันที่ สถานที่ และเวลาท้องถิ่น จริง ๆ แล้วสิ่งที่ต้องการอาจไม่ใช่เขตเวลา ต้องคิดด้วยว่าจะทำอย่างไรหากสถานที่บางแห่งที่ไม่ใช่ลอนดอนถูกย้ายไปอยู่เขตเวลาอื่น
      รูปแบบวันที่-เวลาทั่วไปถูกสร้างขึ้นมาเพื่อแสดงจุดเวลาเฉพาะ แต่ในกรณีนี้ยังไม่มีจุดเวลาเฉพาะแบบนั้น การกำหนดวันที่/เวลาแบบมีโครงสร้างไม่ธรรมดานั้นพบได้บ่อย เช่น ประชุมวันศุกร์สุดท้ายของทุกเดือน ประชุมรายเดือนที่เริ่มวันที่ 31 มกราคม หรือสองวันก่อนสิ้นไตรมาส
      ถ้าจะสร้างมาตรฐานที่ครอบคลุมทุกกรณีที่ผู้คนนึกออก ก็น่าจะซับซ้อนขึ้นอย่างรวดเร็ว หากแค่วันที่ เวลา และ instant แบบง่าย ๆ ไม่พอ ก็ดูเหมือนจะไม่มีทางอื่นนอกจากสร้างโครงสร้างแยกต่างหากที่ใส่องค์ประกอบที่ต้องการทั้งหมด

  • ข้อกำหนด ISO ไม่ได้ให้ใช้ฟรี ดังนั้นโดยทั่วไปควรยึดตาม RFC มากกว่า และการนำไปใช้ในโอเพนซอร์สจำนวนมากก็อิงจากฉบับร่าง จึงพูดได้ยากว่าเป็นมิตรกับโอเพนซอร์สอย่างแท้จริง นี่เป็นภาระใหญ่สำหรับนักพัฒนาโอเพนซอร์สด้วย
    ถ้ากำลังสร้างอะไรที่จัดการวันที่ในอนาคต แทบทุกครั้งเราจะอยากเก็บ เวลาตามนาฬิกาท้องถิ่น + ตำแหน่งที่ตั้ง น่าเสียดายที่ไม่มีมาตรฐานสำหรับเรื่องนี้ ยุโรปและสหรัฐฯ มีเขตเวลาค่อนข้างเสถียรจนอาจไม่ค่อยรู้สึก แต่ในหลายภูมิภาค เขตเวลาเปลี่ยนบ่อย การเก็บค่าออฟเซ็ตจึงไม่เสถียร
    วันที่ 5 มิถุนายน 2026 เวลา 13:30 ตามนาฬิกาท้องถิ่น, ปารีส คือสิ่งที่คนส่วนใหญ่หมายถึง และขึ้นอยู่กับว่า EU จะจัดการเวลาออมแสงอย่างไร จึงอาจเป็น UTC+2 หรือ UTC+1 ก็ได้ ถ้าเป็น API ที่จัดการเวลาในอดีต ก็ใช้ POSIX timestamp เป็นหน่วยวินาที มิลลิวินาที ไมโครวินาที หรือนาโนวินาทีไปได้เลย

    • iCalendar เป็นมาตรฐาน RFC สำหรับเรื่องนี้[1] อย่างไรก็ดี เมื่อเวลาเปลี่ยนเพราะเวลาออมแสง บางเวลาจะมีได้สองรูปแบบการแทนค่า และบางเวลาก็ไม่สามารถแทนด้วยรูปแบบนี้ได้
      iCal เองก็ไม่ได้คำนึงถึงปัญหาที่ตำแหน่งที่ตั้งถูกจัดสรรไปยังเขตเวลาอื่นใหม่ด้วย นอกจากนี้ ไฟล์ iCal ที่ถูกต้องจะรวมข้อมูลเขตเวลาทั้งหมดที่อ้างอิงไว้ ดังนั้นเมื่ออยากแสดงวันที่-เวลาเพียงค่าเดียวจึงยุ่งยาก
      [1] https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.htm...
    • มีมาตรฐานฉบับร่างชื่อ IXDTF ที่ขยาย RFC 3339 โดยใส่ ชื่อเขตเวลา IANA ไว้ในวงเล็บเหลี่ยม: 2026-06-05T13:30+0200[Europe/Paris]
      https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...

  • ส่วนที่มักถูกละเลยในมาตรฐานคือการแสดง duration
    ดูหัวข้อ 5.5.4.2 “Representation of time-interval by duration only” หน้า 21 ใน http://xml.coverpages.org/ISO-FDIS-8601.pdf ได้เลย คงจะดีถ้า JSON parser ในภาษาสแตติกสามารถกำหนดฟิลด์เป็น duration และ serialize เป็นรูปแบบที่ถูกต้องได้
    ตัวอย่างข้อเสนอของ Crystal อยู่ที่นี่: https://github.com/crystal-lang/crystal/issues/11942
    เช่น 15 วัน 5 ชั่วโมง 20 วินาที จะเป็น P15DT5H0M20S และ 7 สัปดาห์จะเป็น P7W

    • หรือจะอ้างอิงนิยาม duration ใน ABNF ของภาคผนวก A ของ RFC 3339 แทนก็ได้
    • ไม่เข้าใจว่าทำไมถึงอยากเก็บข้อมูลที่สามารถจัดโครงสร้างได้ไว้ในรูปแบบสตริง
      เช่นถ้าเขียนเป็น "duration": { "days": 15, "hours": 5, "seconds": 20 } JSON parser ก็ไม่จำเป็นต้องเข้าใจความหมายของข้อมูล ให้ input validator จัดการก็พอ ไม่ว่า JSON จะแทนข้อมูลนี้อย่างไร สุดท้ายก็ต้องมีขั้นตอนแปลงที่อาจล้มเหลวอยู่ดี

  • สิ่งที่ “ตลก” คือ RFC 3339 และ ISO 8601 มีรูปแบบวันที่-เวลาที่ซ้ำซ้อนกันหลายแบบและมีเป้าหมายทับซ้อนกัน แต่ทั้งคู่กลับไม่รวม 2023-09-01 15:30:59 ซึ่งเป็นรูปแบบที่ใช้กันมากที่สุดในทุกระบบและชัดเจนสุด ๆ
    อีกทั้งทั้งสองมาตรฐานยังไม่ชัดเจนมากว่าจะเขียน วันที่ก่อนคริสต์ศักราช และวันที่หลัง 9999-12-31 หรือก่อน -9999-01-01 อย่างไร และไลบรารีทั่วไปส่วนใหญ่มักจัดการไม่ได้เลย ต่อให้จัดการได้ พฤติกรรมของ 00-01-01 ก็แทบอยู่ในระดับที่ไม่ได้ถูกนิยามไว้
    ปฏิทินเกรกอเรียนแปลกตรงที่ปีถัดจาก 1 BC คือ 1 CE และยกเว้นซอฟต์แวร์ดาราศาสตร์เฉพาะทางแล้ว ซอฟต์แวร์แทบทั้งหมดไม่สามารถจัดการช่วงเวลา Unix ที่ไกลจากปัจจุบันมาก ๆ ได้อย่างถูกต้อง แม้แต่เรื่องที่เก็บเป็นสตริงก็พอแล้ว เช่นปีเกิด-ปีตายของจักรพรรดิออกัสตัส มาตรฐานก็ควรนิยามให้ชัดเจน

    • ISO 8601 อนุญาตรูปแบบนั้นได้หากมีข้อตกลงร่วมกัน “ข้อตกลงร่วมกัน” ฟังดูใหญ่โต แต่แค่กำหนดข้อจำกัดง่าย ๆ อย่าง ISO 8601 ที่สามารถเปลี่ยน T เป็นช่องว่างได้ก็พอ RFC 3339 ก็ทำสิ่งคล้ายกันในแบบที่ยืดยาวกว่ามาก
      ก็ยากจะมั่นใจว่า 2023-09-01 15:30:59 เป็นรูปแบบวันที่-เวลาที่ใช้มากที่สุดจริงหรือไม่ ภาษาที่มีผู้ใช้มากที่สุดคือภาษาจีน และตัวคั่นเฉพาะอย่าง 2023年9月1日 ก็พบได้ทั่วไป
      ISO 8601 อนุญาตปีที่ก่อนปี 1582 หรือหลังปี 9999 ได้หากมีข้อตกลงร่วมกัน หากไม่พอดีกับ 4 หลัก ต้องใส่อักขระเครื่องหมายหนึ่งตัวนำหน้า วันที่แบบนี้มีสิ่งที่ทำได้อย่างมีความหมายไม่มาก จึงโดยทั่วไปไม่ค่อยรองรับ แต่ก็เคยเห็นการ parse อยู่พอสมควร โดยเฉพาะในไลบรารีที่ implement แยกจาก C
      00-01-01 ถูกนิยามว่าเป็น วันที่ 1 มกราคม ปี 1 ก่อนคริสต์ศักราช ISO 8601 ระบุชัดเจนว่าหมายเลขปีเป็นไปตามปฏิทินเกรกอเรียนแบบขยายย้อนหลัง (proleptic Gregorian calendar) ดังนั้นจึง extrapolate ไปได้ถึงลบอนันต์
    • รูปแบบที่คั่นด้วยช่องว่างอ่านง่ายกว่ามาก หลังจากทำตามมาตรฐานมาเกือบ 20 ปี ช่วงหลังเริ่มไม่สนใจทั้งสองมาตรฐานและหันไปใช้รูปแบบคั่นด้วยช่องว่างที่ดีกว่าแทน
      เข้าใจเหตุผลที่ต้องมีอักขระที่ไม่ใช่ช่องว่าง แต่เอาเข้าจริงอย่างน้อยก็ใช้ขีดล่างหรือจุดได้ และก็ไม่เข้าใจว่าทำไมถึงจำกัดช่วงปีไว้ที่สี่หลักทั้งที่เป็นสตริง ทำให้ต้องสละความเป็นสากลของรูปแบบไป

  • ปี 6 หลัก ให้ความรู้สึกเหมือนเป็นทางออกของปัญหาที่จริง ๆ จะไม่เกิดขึ้น เพียงเพื่อให้ดูมองไกลไปอนาคต เทคโนโลยีหรือบรรทัดฐานทางสังคมในปัจจุบันไม่น่าจะคงอยู่ไปได้ถึง 8000 ปี

    • เราไม่ได้ใช้คอมพิวเตอร์เฉพาะกับเรื่องที่เกี่ยวข้องกับวันนี้เท่านั้น เช่น ถ้ารัน การคำนวณสภาพภูมิอากาศ ที่ยาวนานมาก ต่อให้เกิดข้อผิดพลาดเพราะวันที่แล้วมองข้ามไปได้ แต่ถ้าไม่เกิดก็น่าจะดีกว่าไหม?
    • ไม่ว่าจะ 5 หลักหรือ 7 หลัก ถ้าเป็นจำนวนหลักที่ทั้งสองฝ่ายตกลงกันได้ก่อนเริ่มสื่อสาร ก็ใช้ได้ ในส่วนที่ 2 ของมาตรฐานยังมีตัวอย่าง ปี 10 หลัก ด้วย
    • ปี 6 หลักเป็นทางออกของปัญหาที่มีอยู่แล้วในตอนนี้ ลองคิดถึง นักธรณีวิทยา ที่จำลองการเคลื่อนที่ของทวีปดู

  • คำอธิบายที่ว่า ISO 8601 ใช้ U+2010 HYPHEN และ U+2212 MINUS และในชุดอักขระที่ไม่มีอักขระดังกล่าวต้องใช้ U+2D HYPHEN-MINUS นั้นไม่ถูกต้อง
    ISO 8601 จริง ๆ ระบุว่า ถ้าชุดอักขระเป้าหมายอิงกับ ISO/IEC 646 ทั้งสองกรณีต้องใช้อักขระ hyphen-minus ซึ่ง Unicode ก็รวมอยู่ในนี้อย่างแน่นอน แม้จะมีความกำกวมอยู่บ้าง แต่ใน Unicode การตีความนั้นชัดเจน และดูเหมือนเป็นวิธีอ้อม ๆ เพื่อรับประกันความเข้ากันได้กับชุดอักขระอื่นที่อิงกับ 646 โดยกำหนดการแมปมาตรฐานของ 646

    • ย่อหน้าที่เกี่ยวข้องอยู่ใน ISO 8601-1:2019 §3.2.1
      เนื้อหาคือ “อักขระทั้งหมดที่ใช้ในการแสดงวันที่และเวลา ยกเว้น ‘hyphen’, ‘minus’, ‘plus-minus’ ล้วนอยู่ใน repertoire ของ ISO/IEC 646 ในสภาพแวดล้อมที่ใช้ character repertoire ซึ่งอิงกับ ISO/IEC 646 ต้องแมปทั้ง ‘hyphen’ และ ‘minus’ เป็น ‘hyphen-minus’”
      Unicode อิงกับ ISO 8859 และ ISO 8859 อิงกับ ISO 646 ดังนั้นในชุดอักขระ Unicode ดูเหมือนเจตนาคือให้ใช้ U+2D hyphen-minus

  • บน Windows เครื่องหมายโคลอนเป็นอักขระพิเศษ จึงมักขัดใจตรงที่เมื่อใส่วันที่และเวลาในชื่อไฟล์ ไม่มีวิธีที่ตรงกับ RFC 3339
    คงจะดีถ้าใช้ขีดกลางในวันที่ แต่ละเว้นโคลอนได้แล้วยังสอดคล้องกับ ISO 8601 เช่น 20230831T1510-0500 นั้นสอดคล้องและใช้ในชื่อไฟล์ได้ แต่ 2023-08-31T1510-0500 และรูปแบบแปรผันที่คล้ายกันกลับไม่สอดคล้อง นอกจากนี้ฟังก์ชัน Get-Date ของ PowerShell ยังไม่เข้าใจ timestamp แบบแรกที่ไม่มีทั้งขีดกลางและโคลอนด้วย

    • การลบโคลอนออกปลอดภัย และไม่ทำให้วันที่กับ date-time ของ RFC 3339 กำกวม สามารถ กู้คืนโคลอนกลับมาได้โดยไม่สูญเสียข้อมูล ทุกเมื่อ
    • ไม่รู้มาก่อนว่า Windows มีปัญหานี้ MacOS ก็มีปัญหาอีกแบบเกี่ยวกับโคลอนในชื่อไฟล์เหมือนกัน ถ้าในสามระบบปฏิบัติการที่ใช้กันมากที่สุดมีถึงสองระบบที่มีปัญหานี้ ก็ถือว่าตอนออกแบบคิดไม่รอบคอบอย่างชัดเจน

  • เป็น visualization ที่ดีมากสำหรับหัวข้อนี้
    เวลาคั่นส่วนวันที่กับเวลา ผมชอบใช้ช่องว่างหรือขีดล่างแทน T มากกว่า แต่โดยมากก็ยังใช้ T ต่อไปเพื่อหลีกเลี่ยงปัญหากับเครื่องมือที่จัดการเฉพาะ ISO 8601 และเพื่อความสม่ำเสมอ

    • ชอบ T มากกว่า เพราะคงไม่มีใครเผลอแบ่งสตริงแบบนี้โดยอิงจาก T

  • สงสัยอยู่สองอย่าง อย่างแรก เหตุผลของ ปีแบบ 6 หลัก คืออะไร? ระบบใด ๆ ที่ออกแบบขึ้นตอนนี้คงไม่มีทางยังอยู่ในปี 100,000 ไม่ใช่หรือ
    อย่างที่สอง ISO 8601 แพร่หลายมาก แล้ว RFC 3339 ก็ถูกใช้และนำไปใช้จริงในระบบต่าง ๆ มากเหมือนกันไหม?

    • ดูจากเวลาที่ต้องใช้กว่าจะหลุดพ้นจากเทคโนโลยีเก่า ๆ ได้อย่างสมบูรณ์ ถึงปี 100,000 ถ้ายังมีการ จำลอง x86 บนคอมพิวเตอร์ควอนตัมอยู่ก็คงไม่น่าแปลกใจ
    • เวลาที่ไลบรารีบอกว่าเป็น ISO 8601 สัก 90% มักไม่ได้ implement ไปถึงส่วนที่เข้าใจยากกว่าของ ISO 8601 จริง ๆ
    • แพ็กเกจ time อย่างเป็นทางการของ Golang และ Chrono ของ Rust มีเครื่องมือในตัวสำหรับจัดการ RFC 3339 แต่ไม่มีสำหรับ RFC 8601
      เท่าที่จำได้ RFC 8601 มีปัญหาความกำกวมที่ RFC 3339 ไม่มี และ Python ก็เคยมีปัญหาในการแปลงวันที่ไป-กลับด้วยเหตุนี้
    • ถ้าเป็นเครื่องมือทางวิทยาศาสตร์ ก็อาจอยากแสดงวันที่ในอนาคตอันไกลได้
    • Y10k (:

  • ไม่มีรูปแบบที่ระบุ timezone เป็นตัวเลขสี่หลักแบบไม่มีโคลอน แต่ date +%z คืนค่าเป็น ±NNNN

    • โชคดีที่มี %:z ในเรื่องนี้ยังสอนให้ date แสดงผลแบบนี้เป็นค่าเริ่มต้นได้ด้วย: https://gist.github.com/d081dad407432d53172e30d0d35c39db
      $ date
      2023-08-31T11:15:00-07:00
    • ±NNNN ถ้าใช้เป็นส่วนหนึ่งของ “รูปแบบพื้นฐาน” ก็ถือว่าถูกต้องแม้ไม่มีโคลอน กล่าวคือ ทั้งรูปแบบต้องไม่มีขีดกลางหรือโคลอนเลย
      ดังนั้นสองรายการต่อไปนี้เทียบเท่ากันและถูกต้องทั้งคู่:
      2023-09-01T09:40:01+08:00
      20230901T094001+0800