RFC 3339 और ISO 8601 की तुलना

 (ijmacd.github.io)
3 पॉइंट द्वारा GN⁺ 2023-09-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • तारीख़ और समय के notation को संभालते समय RFC 3339 वेब और इंटरनेट में आसानी से इस्तेमाल होने वाले एक संकरे subset के करीब है, जबकि ISO 8601-1:2019 कहीं ज़्यादा व्यापक format set शामिल करता है
  • तुलना का दायरा ISO 8601-1:2019 तक सीमित है, और ISO 8601-2:2019 की season, set, uncertainty qualification, date arithmetic जैसी अतिरिक्त expressions अभी table में शामिल नहीं हैं
  • दोनों standards 2026-06-26, 14:08:00Z, 2026-06-26T14:08:00Z, +00:00 offset जैसे व्यापक रूप से इस्तेमाल होने वाले basic date-time formats को कवर करते हैं
  • ISO 8601 century, decade, ordinal day, week date, abbreviated time, comma decimal, period (P1Y) और range (2026-06-26/P1Y) तक को शामिल करता है, लेकिन RFC 3339 में table में इनमें से ज़्यादातर बाहर रखे गए हैं
  • Date-Time notation में T separator और case sensitivity, -00:00 offset जैसे अंतर असल parser compatibility तय करने वाले points बन जाते हैं

तुलना का दायरा और पूर्वधारणाएँ

  • format table पूरी सूची नहीं है
  • target standard ISO 8601-1:2019 है
    • पुराने editions और drafts में महत्वपूर्ण अंतर हैं
  • ISO 8601-2:2019 अतिरिक्त expressions शामिल करता है, लेकिन इस page में अभी शामिल नहीं है
    • sub-year groups, उदाहरण के लिए seasons
    • grouping units
    • sets
    • uncertainty qualification
    • date arithmetic
  • RFC 3339 सुझाव देता है कि downstream standards में T को किसी दूसरे character से बदला जा सकता है, लेकिन examples में केवल space character दिया गया है
  • हर standard उद्देश्य-विशेष formats define करता है, और बाकी formats की सिफ़ारिश नहीं की जाती

date notation में ISO 8601 ज़्यादा व्यापक है

  • RFC 3339 और ISO 8601 दोनों 2026-06-26 जैसी year-month-day date support करते हैं
  • ISO 8601, RFC 3339 की तुलना में date expressions की ज़्यादा variety कवर करता है
    • century: 20
    • decade: 202
    • year: 2026
    • year-month: 2026-06
    • ordinal day: 2026-177
    • week date: 2026-W26, 2026-W26-5
    • basic format: 20260626, 2026177, 2026W26, 2026W265
  • table में RFC 3339 ऊपर दिए गए ISO-only date formats की अनुमति नहीं देता

time notation के अंतर

  • दोनों standards 14:08:00Z, 14:08:00+00:00, 14:08:00.372+00:00 जैसे second-level time और timezone offset को अनुमति देते हैं
  • RFC 3339 case-sensitive नहीं है, इसलिए T और Z को क्रमशः t, z के रूप में लिखा जा सकता है
    • ISO 8601 के पुराने editions भी case-sensitive नहीं थे
  • ISO 8601 सबसे छोटी time value में fractional part जोड़ने की अनुमति देता है
    • table में मुख्यतः एक decimal digit वाले examples हैं, लेकिन standard arbitrary precision की अनुमति देता है
    • decimal separator के रूप में comma और dot दोनों की अनुमति है, और सभी formats में इन्हें एक-दूसरे की जगह इस्तेमाल किया जा सकता है
  • ISO 8601-1:2019 ambiguity न होने पर time-only expression में T छोड़ने की अनुमति देता है
  • ISO 8601 14, 14:08, 14:08:00, 140800, T14:08:00, 14:08:00,372 जैसे abbreviated, basic और comma-decimal time expressions support करता है
  • RFC 3339 14:08:00-00:00 जैसे -00:00 offset की अनुमति देता है, लेकिन table में ISO 8601 इसकी अनुमति नहीं देता

Date-Time में T और separator

  • RFC 3339 और ISO 8601 दोनों 2026-06-26T14:08:00Z और 2026-06-26T14:08:00+00:00 जैसे Date-Time को अनुमति देते हैं
  • ISO 8601 के Date-Time expression में T हमेशा ज़रूरी है
    • पुराने editions में Date-Time में T छोड़ना भी allowed था
    • पुराने editions में भी space या underscore जैसे वैकल्पिक characters insert करने की अनुमति नहीं थी
  • table में RFC 3339 निम्न Date-Time variants को अनुमति देता है
    • lowercase t और z: 2026-06-26t14:08:00z
    • space separator: 2026-06-26 14:08:00Z
    • underscore separator: 2026-06-26_14:08:00Z
    • -00:00 offset: 2026-06-26T14:08:00-00:00
  • ISO 8601 2026-06-26T14, 2026-06-26T14:08, 2026-06-26T14:08:00, 2026-177T14:08, 2026-W26-5T14:08 जैसे abbreviated Date-Time और ordinal day, week date based Date-Time को कवर करता है

periods और ranges ISO 8601 केंद्रित हैं

  • table में Periods formats केवल ISO 8601 के लिए checked हैं
    • उदाहरण: P1Y, P1M, P1W, P1D
    • time शामिल examples: PT1H, PT1M, PT1S
    • combination example: P1Y1M1DT1H1M1S
    • fractional examples: P1.5Y, P1,5W, PT1.5S
  • Ranges formats भी केवल ISO 8601 के लिए checked हैं
    • date और period: 2026-06-26/P1Y
    • date और date: 2026-06-26/2026-06-26
    • period और date: P1Y/2026-06-26
    • Date-Time और period: 2026-06-26T14:08/P1DT1H
    • repeating range: R/2026-06-26/P1Y, R10/2026-06-26/P1Y

format keys और test tool

  • format table %Y, %M, %D, %h, %m, %s जैसे format keys का इस्तेमाल करता है
    • %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: timezone hour, जिसमें + या - शामिल है
    • %z: timezone minute
  • format checker केवल यह verify करता है कि input format table के formats में आता है या नहीं
    • यह सभी possible formats को check नहीं करता
  • ISO 8601 as a Service beta testing के लिए service है
    • फिलहाल केवल Date, Time, DateTime support करता है
    • Period और Range support नहीं करता
  • source GitHub पर public है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-09-01
Hacker News टिप्पणियां

  • यह अजीब है कि किसी खास time zone के आधार पर भविष्य की तारीख/समय बताने का कोई तरीका नहीं है। उदाहरण के लिए, आप 1 जुलाई 2030 को लंदन के स्थानीय समयानुसार शाम 6 बजे की meeting सेट करना चाह सकते हैं, और बीच में UK के time zone नियम जैसे भी बदलें, वह “लंदन में शाम 6 बजे” ही रहना चाहिए
    अभी UK लगभग नवंबर–मार्च में Z+00:00 और अप्रैल–अक्टूबर में summer time Z+01:00 इस्तेमाल करता है[0], लेकिन 2030 से पहले वह Central European Time[1] अपना सकता है, British Double Summer Time[2] फिर से आज़मा सकता है, या summer time खत्म भी कर सकता है। इसलिए वही “शाम 6 बजे” किसी खास epoch के हिसाब से काफी अलग हो सकता है
    calendar event में “उस समय के लंदन time में शाम 6 बजे” डालना चाहता हूं, लेकिन 2030-07-01 18:00:00 Europe/London को standard और interoperable तरीके से व्यक्त करने का कोई तरीका नहीं है
    [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...

    • ऐसे format के लिए एक draft document IXDTF (Internet Extended Date/Time Format) है[0]। RFC 3339 string के बाद square brackets में tz नाम से time zone जोड़ा जा सकता है, और local time व्यक्त करने के लिए UTC offset का अनुमानित मान भी साथ लिखना पड़ता है
      उदाहरण के लिए 2030-07-01 18:00:00 Europe/London, 2030-07-01T18:00:00+01:00[Europe/London] बनता है। अगर उससे पहले UK के नियम बदल जाएं तो timestamp “mismatch” हो जाएगा, और application तय करेगी कि उसे कैसे handle करना है। हालांकि square brackets में time zone नाम से पहले ! डालने पर UTC offset को आंख मूंदकर मानने के बजाय समस्या detect करनी होगी
      यह extended timestamp format JavaScript की प्रस्तावित Temporal library[1] में भी इस्तेमाल होता है, और ZonedDateTime.from() parsing function[2] mismatch timestamp में किस पक्ष को प्राथमिकता देनी है, यह offset option से control करने देता है। UTC offset हटाकर केवल time zone लिखना भी supported है, लेकिन यह चेतावनी देता है कि summer time transition के दौरान दोहराया जाने वाला एक घंटे का interval ambiguous होता है
      [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...
    • असल में time zone से भी ज्यादा specific जानकारी चाहिए लगती है। उदाहरण के लिए, अगर आप लंदन नहीं बल्कि Scotland के Glasgow में 1 जुलाई 2030 को शाम 6 बजे मिलना चाहते हों, तो अभी Glasgow Europe/London time zone में है
      लेकिन इस बीच Scotland फिर से independence referendum कराकर Central European Time में शामिल हो जाए या Scottish Standard Time बना दे, यह कल्पना से बाहर नहीं है
    • ऐसी अभिव्यक्ति का जाल यह है कि ambiguous या impossible timestamps बनते हैं। 2023-11-05 01:30:00 America/New_York दो अलग-अलग समयों में से कोई एक हो सकता है
      calendar में “wall clock पर वही समय” आम तौर पर वांछित अर्थ होता है, इसलिए यह ठीक है, लेकिन अजीब समयों को handle करने में UI की कठिनाई है और आप syntax में ambiguity resolve करने का तरीका डालना चाह सकते हैं। आम तौर पर ये transitions आधी रात को होते हैं, यह अच्छी बात है, लेकिन असली कामकाज में मैंने ऐसा होते देखा है
      अगर आप ऐसे time zone के व्यक्ति को invite करते हैं जहां summer time नहीं है, तो उसके calendar में समय डोलता रहेगा, और कभी-कभी international colleagues को यह सहना पड़ता है
    • calendar की दुनिया में iCal में यह पहले से supported है। बिना time zone वाला date-time केवल local time का मतलब रखता है[0]
      [0]: https://www.rfc-editor.org/rfc/rfc5545#section-3.3.5
    • जरूरी जानकारी तीन चीजें हैं: तारीख, location, और local time। असल में शायद आपको time zone नहीं चाहिए। अगर लंदन के बजाय कोई और जगह दूसरे time zone में चली जाए तो क्या करना है, यह सोचना होगा
      आम date-time formats किसी खास instant को व्यक्त करने के लिए बनाए गए थे, लेकिन इस मामले में ऐसा कोई खास instant अभी है ही नहीं। हर महीने के आखिरी शुक्रवार की meeting, 31 जनवरी को शुरू होने वाली monthly meeting, quarter-end से दो दिन पहले जैसी date/time specifications का non-trivial structure होना आम बात है
      लोग जिन सभी cases की कल्पना कर सकते हैं उन्हें cover करने वाला standard बनाना जल्दी ही जटिल हो जाएगा। अगर simple date, time, और instant पर्याप्त नहीं हैं, तो लगता है कि आवश्यक सभी elements रखने वाला अलग structure बनाना ही पड़ेगा

  • ISO स्पेसिफिकेशन मुफ्त में उपलब्ध नहीं है, इसलिए आम तौर पर RFC का पालन करना बेहतर होता है, और कई open source implementations भी draft पर आधारित हैं, इसलिए इसे पूरी तरह open source-friendly कहना मुश्किल है। open source developers के लिए भी यह बड़ा बोझ है
    अगर आप भविष्य की तारीखों से जुड़ी कोई चीज़ बना रहे हैं, तो लगभग हमेशा wall-clock time + location को स्टोर करना चाहेंगे। दुर्भाग्य से इसके लिए कोई standard नहीं है। यूरोप और अमेरिका में time zones काफ़ी स्थिर हैं, इसलिए यह बात शायद ज़्यादा महसूस न हो, लेकिन कई क्षेत्रों में time zones अक्सर बदलते हैं, इसलिए offset स्टोर करना स्थिर नहीं है
    2026년 6월 5일 13:30 벽시계, 파리 वही है जो अधिकतर लोग कहना चाहते हैं, और EU daylight saving time के साथ क्या करेगा, इस पर निर्भर करते हुए यह UTC+2 भी हो सकता है या UTC+1 भी। अगर API अतीत के समय को संभालती है, तो बस seconds, milliseconds, microseconds, nanoseconds की units में POSIX timestamp इस्तेमाल कर लेना चाहिए

    • iCalendar इसके लिए एक RFC standard है[1]। हालांकि daylight saving time की वजह से समय बदलने पर कुछ समयों के दो representations होते हैं, और कुछ समयों को इस format में represent नहीं किया जा सकता
      iCal भी location को अलग time zone में reassign किए जाने की समस्या तक पर विचार नहीं करता। साथ ही, सही iCal file में refer किए गए सभी time zone data शामिल होते हैं, इसलिए जब केवल एक date-time output करना हो तो यह झंझट भरा है
      [1] https://icalendar.org/iCalendar-RFC-5545/3-3-5-date-time.htm...
    • RFC 3339 को extend करके square brackets में IANA time zone name डालने वाला IXDTF नाम का एक draft standard है: 2026-06-05T13:30+0200[Europe/Paris]
      https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-e...

  • standards में अक्सर नज़रअंदाज़ किया जाने वाला हिस्सा duration का representation है
    http://xml.coverpages.org/ISO-FDIS-8601.pdf के 5.5.4.2 “Representation of time-interval by duration only”, पेज 21 को देखना चाहिए। अच्छा होगा अगर static languages के JSON parsers किसी field को duration के रूप में define करने और valid format में serialize करने दें
    Crystal का proposal example यहां है: https://github.com/crystal-lang/crystal/issues/11942
    उदाहरण के लिए 15 दिन 5 घंटे 20 सेकंड P15DT5H0M20S होगा, और 7 सप्ताह P7W

    • इसकी जगह RFC 3339 Appendix A के ABNF में मौजूद duration definition को भी refer किया जा सकता है
    • जो data structured हो सकता है, उसे string format में क्यों रखना चाहेंगे, यह समझ नहीं आता
      उदाहरण के लिए "duration": { "days": 15, "hours": 5, "seconds": 20 } जैसा लिखें तो JSON parser को data का अर्थ समझने की ज़रूरत नहीं है; input validator इसे संभाल सकता है। वैसे भी JSON इस data को जिस भी तरह represent करे, failure की संभावना वाला एक conversion step तो चाहिए ही

  • RFC 3339 और ISO 8601 में overlapping उद्देश्य वाले कई redundant date-time formats शामिल हैं, फिर भी सभी systems में सबसे ज़्यादा इस्तेमाल होने वाला और बिल्कुल obvious 2023-09-01 15:30:59 दोनों में शामिल नहीं है—यह “मज़ेदार” है
    साथ ही दोनों standards BCE dates और 9999-12-31 के बाद या -9999-01-01 से पहले की dates को कैसे represent करना है, इस बारे में बहुत unclear हैं, और आम libraries आम तौर पर इन्हें बिल्कुल handle नहीं कर पातीं। अगर कर भी लें, तो 00-01-01 का behavior practically undefined जैसा है
    Gregorian calendar अजीब है क्योंकि 1 BC के बाद अगला साल 1 CE होता है, और specialist astronomy software को छोड़कर लगभग सभी software निकट भविष्य के Unix time range के बाहर ठीक से handle नहीं कर पाते। Augustus emperor के जन्म-मृत्यु वर्ष जैसी चीज़ों को string के रूप में store कर देना भी पर्याप्त हो सकता है, बस standard इसे स्पष्ट रूप से define कर दे

    • ISO 8601 mutual agreement होने पर उस format की अनुमति देता है। “mutual agreement” सुनने में भारी लगता है, लेकिन बस ISO 8601 जैसी सरल qualification जोड़नी होती है कि T को space से बदला जा सकता है। RFC 3339 भी कहीं अधिक verbose तरीके से कुछ ऐसा ही करता है
      यह भी पक्का कहना मुश्किल है कि 2023-09-01 15:30:59 सबसे ज़्यादा इस्तेमाल होने वाला date-time format है। सबसे ज़्यादा इस्तेमाल होने वाली भाषा Chinese है, और 2023年9月1日 जैसे अपने separators आम हैं
      ISO 8601 mutual agreement होने पर 1582 से पहले या 9999 के बाद के years की भी अनुमति देता है। अगर 4 digits में fit नहीं होता, तो आगे एक single sign character लगाना चाहिए। ऐसी dates के साथ meaningful तरीके से करने लायक चीज़ें कम होती हैं, इसलिए वे आम तौर पर supported नहीं होतीं, लेकिन खासकर C से स्वतंत्र रूप से implemented libraries में इन्हें parse करते हुए मैंने काफ़ी देखा है
      00-01-01 को 1 BCE January 1 के रूप में define किया गया है। ISO 8601 स्पष्ट करता है कि year numbering proleptic Gregorian calendar का पालन करती है, इसलिए इसे negative infinity तक extrapolate किया जाता है
    • space से separated format कहीं अधिक readable है। लगभग 20 साल तक standard follow करने के बाद, हाल में मैंने दोनों को ignore करके बेहतर space-separated format की तरफ़ जाना शुरू किया है
      मुझे समझ है कि non-space character की ज़रूरत क्यों थी, लेकिन कम से कम underscore या dot भी इस्तेमाल किया जा सकता था। और यह भी समझ नहीं आता कि string होते हुए भी year segment को चार digits तक सीमित करके format की universality क्यों sacrifice की गई

  • 6-digit year भविष्यवादी दिखने के लिए, असल में कभी न आने वाली समस्या का समाधान जैसा लगता है। मौजूदा technology या social norms के 8000 साल तक बने रहने की कोई संभावना नहीं है

    • Computers का इस्तेमाल केवल आज से जुड़ी चीज़ों के लिए नहीं होता। उदाहरण के लिए अगर बहुत लंबी climate calculation चलानी हो, तो date की वजह से error आए तो उसे ignore किया जा सकता है, लेकिन अगर error न आए तो बेहतर नहीं होगा?
    • 5 digits हों या 7 digits, communication शुरू करने से पहले दोनों पक्ष जितने digits पर agree कर सकें, वे इस्तेमाल किए जा सकते हैं। standard के part 2 में 10-digit year का example भी है
    • 6-digit year आज भी मौजूद समस्या का समाधान है। geologist द्वारा continental drift simulate करने के बारे में सोचें

  • यह व्याख्या गलत है कि ISO 8601 U+2010 HYPHEN और U+2212 MINUS का उपयोग करता है, और जिन character sets में वे characters नहीं हैं, वहाँ U+2D HYPHEN-MINUS इस्तेमाल करना चाहिए
    असल ISO 8601 स्पष्ट करता है कि अगर target character set ISO/IEC 646 आधारित है, तो दोनों मामलों में hyphen-minus character ही इस्तेमाल करना चाहिए। इसमें Unicode निश्चित रूप से शामिल है। थोड़ी अस्पष्टता है, लेकिन Unicode में interpretation साफ है, और यह 646 की standard mapping निर्दिष्ट करके 646 आधारित दूसरे character sets के साथ compatibility सुनिश्चित करने का अप्रत्यक्ष तरीका लगता है

    • संबंधित paragraph ISO 8601-1:2019 §3.2.1 में है
      इसका आशय है: “date और time expressions में इस्तेमाल होने वाले सभी characters, ‘hyphen’, ‘minus’, ‘plus-minus’ को छोड़कर, ISO/IEC 646 repertoire में आते हैं। ISO/IEC 646 आधारित character repertoire इस्तेमाल करने वाले environments में ‘hyphen’ और ‘minus’ दोनों को ‘hyphen-minus’ पर map करना चाहिए”
      Unicode ISO 8859 आधारित है और ISO 8859, ISO 646 आधारित है, इसलिए Unicode character set में U+2D hyphen-minus इस्तेमाल करने का इरादा सही लगता है

  • Windows में colon एक special character है, इसलिए file name में date और time डालते समय RFC 3339 के अनुरूप कोई तरीका न होना अक्सर खटकता है
    अच्छा होता अगर date में hyphen इस्तेमाल करते हुए colon हटाने पर भी ISO 8601 का पालन हो सकता। उदाहरण के लिए 20230831T1510-0500 compliant है और file name में इस्तेमाल किया जा सकता है, लेकिन 2023-08-31T1510-0500 और मिलते-जुलते variants compliant नहीं हैं। साथ ही, PowerShell का Get-Date function hyphen और colon के बिना वाले पहले timestamp को समझ नहीं पाता

    • colon हटाना भी safe है और RFC 3339 date और date-time को ambiguous नहीं बनाता। कभी भी बिना loss के colon restore किए जा सकते हैं
    • मुझे नहीं पता था कि Windows में यह problem है। MacOS में भी file name में colon को लेकर अलग समस्या है। अगर सबसे ज्यादा इस्तेमाल होने वाले तीन operating systems में से दो में यह problem है, तो design में निश्चित रूप से सोच की कमी रही

  • इस topic पर यह बहुत अच्छी visualization है
    date और time वाले हिस्सों को अलग करते समय T की जगह space या underscore पसंद है, लेकिन ISO 8601-only processing से जुड़ी समस्याओं से बचने और consistency के लिए आम तौर पर T ही इस्तेमाल करता हूँ

    • मुझे T पसंद है। ऐसी string को गलती से T के आधार पर split करने की नौबत नहीं आएगी

  • दो बातें जाननी हैं। पहली, 6-digit year का आधार क्या है? अभी design किया गया कोई भी system 100,000 साल में मौजूद होने वाला नहीं है, है न
    दूसरी, ISO 8601 तो व्यापक है, लेकिन क्या RFC 3339 भी real systems में खूब इस्तेमाल और adopt हुआ है?

    • पुरानी technology से पूरी तरह छुटकारा पाने में लगने वाला समय देखकर, 100,000 साल बाद भी quantum computers पर x86 emulation चल रही हो तो मुझे आश्चर्य नहीं होगा
    • जब कोई library कहती है कि वह ISO 8601 है, तो 90% मामलों में वह वास्तव में ISO 8601 के ज्यादा obscure हिस्से implement नहीं करती
    • Golang के official time package और Rust के Chrono में RFC 3339 के लिए built-in tools हैं, लेकिन RFC 8601 के लिए नहीं
      याद है कि RFC 8601 में RFC 3339 में न होने वाली ambiguity issues थीं, और इसी वजह से Python में भी date round-trip conversion में समस्याएँ थीं
    • अगर scientific tool हो, तो हो सकता है कि वह बहुत दूर के future की dates represent करना चाहे
    • Y10k (:

  • ऐसा कोई format नहीं है जिसमें timezone colon के बिना चार digits से specified हो, लेकिन date +%z ±NNNN return करता है

    • सौभाग्य से %:z मौजूद है। इसी से जुड़ा, date को default रूप से ऐसा output करने के लिए भी सिखाया जा सकता है: https://gist.github.com/d081dad407432d53172e30d0d35c39db
      $ date
      2023-08-31T11:15:00-07:00
    • ±NNNN अगर “basic format” के हिस्से के रूप में इस्तेमाल हो, तो colon के बिना भी valid है। यानी पूरे format में कहीं भी hyphen या colon नहीं होना चाहिए
      इसलिए ये दोनों equivalent हैं और दोनों valid हैं:
      2023-09-01T09:40:01+08:00
      20230901T094001+0800