I don't think we can (trivially without deprecation cycles) remove support for the leading minus to move back into spec, so for this reason alone we are committed for a while to not being spec compliant.
Probably a good juncture to ask: should we just commit to not being spec compliant, shore up the docs around how we handle date parsing? In an ideal world that also kinda implies a deprecation cycle where we try to move away from "ISO" related terminology in module and function names, which is probably even a bigger pain though... On Thursday, February 4, 2021 at 3:55:24 PM UTC-8 Christopher Keele wrote: > So by my read, the leading minus is part of the expanded year spec, and > the expanded year spec is by agreement only, because all parties have to > agree on how much the year is being expanded, to avoid ambiguity with basic > ordinal notation. > > What a tangled web we weave! > On Thursday, February 4, 2021 at 3:53:20 PM UTC-8 Christopher Keele 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/96ca65d8-0275-4781-9f8c-64332f63209an%40googlegroups.com.
