The most straight-forward source I've been referencing is the wikipedia page on ISO-8601, augmented by the spec itself and some explanatory articles for confusing cases. But the wiki does a good job <https://en.wikipedia.org/wiki/ISO_8601#Years> with this one:
> It therefore represents years from 0000 to 9999, year 0000 being equal to 1 BC and all others AD. > To represent years before 0000 or after 9999, the standard also permits... [A]n expanded year representation ±*Y*YYYY [that] must have an agreed-upon number of extra year digits beyond the four-digit minimum, and it must be prefixed with a + or − sign. Additionally: > The expansion of the year representation[must be used] only by prior agreement between the sender and the receiver. Also concerning: > Values in the range [0000] through [1582] shall only be used by mutual agreement of the partners in information interchange. On Thursday, February 4, 2021 at 3:46:04 PM UTC-8 José Valim wrote: > > In fact now that I think about it we are probably violating the spec > today: we support negative signs to indicate BC for 4-digit years. By my > reading of the spec we should be requiring that negative years supply 5 > digits. > > My understanding is that the number of extra digit years is adjustable. So > it could be 0 extra digits or even 2. To quote Wikipedia: > > > The "basic" format for year 0 is the four-digit form 0000, which equals > the historical year 1 BC. Several "expanded" formats are possible: −0000 > and +0000, as well as five- and six-digit versions. > > Source: https://en.m.wikipedia.org/wiki/Year_zero > > I am not sure if this means the basic format does not support extra digits > nor negative years. If they do, then there may be ambiguity. > > On Fri, Feb 5, 2021 at 00:22 Christopher Keele <[email protected]> > wrote: > >> > Here is another question: if we are going to parse ordinals by default, >> how am I going to format to the ordinal format? Use strftime exclusively? >> >> I'm fine with that, to me this is a case of following the parsing spec >> and being liberal in what we accept, conservative in what we emit (by >> default). >> >> On Thursday, February 4, 2021 at 3:20:21 PM UTC-8 Christopher Keele wrote: >> >>> > Ordinal also has both extended and basic forms too. >>> >>> Yup, basic/extended can apply to the entire date/time/datetime string >>> (but must be universally applied to it, saving at least some headache). >>> >>> > The distinction between basic ordinal and basic DateTime is a single >>> character >>> >>> I agree that basic ordinals is possibly the worst way to format a date, >>> for the reasons you describe. But it is technically unambiguous, and >>> >>> > There will also be ambiguity if we ever decide to support more than >>> four digits on the year. >>> >>> This is technically not true for 5-digit years, so long as we choose to >>> use ISO-8601: it has a provision for this by prefixing the year with a plus >>> or minus. This is described as being 'by agreement only' though so omitted >>> from my envisioned scope. >>> >>> In fact now that I think about it we are probably violating the spec >>> today: we support negative signs to indicate BC for 4-digit years. By my >>> reading of the spec we should be requiring that negative years supply 5 >>> digits. >>> >>> > At this point I wonder why add [ordinal dates] to the stdlib. >>> >>> My motive here really is just to be spec-compliant. There may be a point >>> where we decide we are going off-spec to avoid many of the complexities >>> raised in this discussion, happy to have that conversation too (though >>> probably should be its own thread?) >>> On Thursday, February 4, 2021 at 3:08:00 PM UTC-8 José Valim wrote: >>> >>>> Ah, thanks Kip. Ordinal also has both extended and basic forms too. >>>> >>>> Here is another question: if we are going to parse ordinals by default, >>>> how am I going to format to the ordinal format? Use strftime exclusively? >>>> >>>> The other annoyance is while an extended ordinal is distinct enough >>>> from a regular extended DateTime, the distinction between basic ordinal >>>> and >>>> basic DateTime is a single character: “2020012134523”. There will also be >>>> ambiguity if we ever decide to support more than four digits on the year. >>>> This is enough to say that: >>>> >>>> * it is not possible to parse all formats within a single function >>>> without additional user instructions >>>> >>>> * if the basic format supports both regular and ordinal, there can be >>>> ambiguity if 5 year digits are ever supported in the future >>>> >>>> This is enough information to me that ordinal should be its own thing, >>>> with possibly basic_ordinal and extended_ordinal, but at this point I >>>> wonder why add it to the stdlib. >>>> >>>> On Thu, Feb 4, 2021 at 23:50 Kip Cole <[email protected]> wrote: >>>> >>>>> From ISO 8601-1:2019(E): >>>>> >>>>> 5.2.3 Ordinal date >>>>> >>>>> >>>>> 5.2.3.1 Complete representations >>>>> >>>>> A complete representation of an ordinal date shall be as follows. >>>>> >>>>> a) Basic format: [year][dayo] EXAMPLE 1 1985102 >>>>> >>>>> b) Extended format: [year][“-”][dayo] EXAMPLE 2 1985-102 >>>>> >>>>> If by agreement, expanded representations are used, the formats shall >>>>> be as specified below. The interchange parties shall agree on the >>>>> additional number of digits in the time scale component year. >>>>> >>>>> 5.2.3.2 Expanded representations >>>>> >>>>> In the examples below it has been agreed to expand the time scale >>>>> component year with two digits. >>>>> >>>>> a) Basic format: [±][year(6)][dayo] EXAMPLE 1 +001985102 >>>>> >>>>> b) Extended format: [±][year(6)][“-”][dayo] EXAMPLE 2 +001985-102 >>>>> >>>>> On 5 Feb 2021, at 6:45 am, José Valim <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>>> I like José's suggesting of supporting a flag, but it gets kind of >>>>>> complicated as there are several dimensions here even in our reduced >>>>>> case. >>>>>> Dates, times, and datetimes support either basic or extended notations; >>>>>> dates and datetimes support calendar dates or ordinal dates; both are >>>>>> applicable to any parsing. >>>>>> >>>>> >>>>> Are we 100% sure that ordinal datetimes are part of ISO8601? Kip, can >>>>> you please confirm? >>>>> >>>>> >>>>>> If we went with this approach I'd lean towards always accepting >>>>>> either form for one of the dimensions, and using flags to the sigil and >>>>>> parsing functions to indicate intent for the other. >>>>>> >>>>> >>>>> I am not necessarily worried about sigils because sigils are always >>>>> compile-time literals. It is probably fine to enforce a given format >>>>> there >>>>> rather than multiple ones. >>>>> >>>>> >>>>> -- >>>>> You received this message because you are subscribed to a topic in the >>>>> Google Groups "elixir-lang-core" group. >>>>> To unsubscribe from this topic, visit >>>>> https://groups.google.com/d/topic/elixir-lang-core/CcXpeMQhsmU/unsubscribe >>>>> . >>>>> To unsubscribe from this group and all its topics, send an email to >>>>> [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JNeGkCNW_6ic2XkxTkFV3uyMT%2B3EZYJuguhzzZfpOnpQ%40mail.gmail.com >>>>> >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4JNeGkCNW_6ic2XkxTkFV3uyMT%2B3EZYJuguhzzZfpOnpQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> >>>>> -- >>>>> >>>> You received this message because you are subscribed to the Google >>>>> Groups "elixir-lang-core" group. >>>>> >>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/elixir-lang-core/15198E56-9D02-4A0E-8E6D-AB905531112A%40gmail.com >>>>> >>>>> <https://groups.google.com/d/msgid/elixir-lang-core/15198E56-9D02-4A0E-8E6D-AB905531112A%40gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> -- >> You received this message because you are subscribed to the Google Groups >> "elixir-lang-core" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/elixir-lang-core/d23cddf9-5f10-4618-b6c7-a0902b828bd2n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/d23cddf9-5f10-4618-b6c7-a0902b828bd2n%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/f1636d39-4a9d-4206-b6da-33a10b8e42c6n%40googlegroups.com.
