Correct, the number of extra digits can be zero. And since we do support negative years, it is a representation we need to support.
This conversation makes me think that the simplest is to not support ordinal dates. We will simply support what is required to represent our own data. So if we ever support 5 digit years internally, then we change the formatting/parsing functions too, but not before. That is supported by the spec because everything on ISO is per agreement. unless it explicitly says that supporting the regular format also requires supporting the ordinal one. On Fri, Feb 5, 2021 at 00:53 Christopher Keele <[email protected]> wrote: > 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 > <https://groups.google.com/d/msgid/elixir-lang-core/f1636d39-4a9d-4206-b6da-33a10b8e42c6n%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/CAGnRm4J1962bJkQFOES%2B9VCbhQTYa6ds0cKBcjj_ZJ7qVnXKzw%40mail.gmail.com.
