> 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/CAGnRm4Lxe9tgq%3DHhBaPiyYmdj%3DJHG2WKN3RqPzWi2t0FvuSEvw%40mail.gmail.com.
