Sounds great to me, I'll start a PR. On Thursday, February 4, 2021 at 4:27:28 PM UTC-8 Kip wrote:
> > So my takeaway is that if we add some docs around our choices here, and > our use of the year extension for the minus, and support leading plusses, > we are in spec without adding ordinal date or basic format support. > > Yes, I think for the std lib, being clear on the implementation scope is a > good idea. If we think about this pragmatically, the common use cases are > parsing machine generated dates like in HTTP headers. Less about parsing > human readable UI content. So restricting conformance and documenting > clearly seems sound. > > > > On 5 Feb 2021, at 8:23 am, Christopher Keele <[email protected]> wrote: > > It also goes on to say "When the application identifies the need for a > complete representation of a calendar date, it shall *be one of *the > numeric expressions as follows". So we can in fact ditch the ordinal > support! > > So my takeaway is that if we add some docs around our choices here, and > our use of the year extension for the minus, and support leading plusses, > we are in spec without adding ordinal date or basic format support. > > On Thursday, February 4, 2021 at 4:17:58 PM UTC-8 Christopher Keele wrote: > >> > 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. >> >> Hmm, would love Kip's take on this, but based on my reading: >> >> - The minus sign comes with the year extension. Extension support is >> optional, with mutual agreement on how much they are extended, and as you >> point out, extending it by 0 digits is valid. >> So we could just document how we've chosen to support this. But we'd >> need to add support for a leading plus as well. >> >> - Neither basic and extended support, nor calendar vs ordinal date >> support, mentions mutual agreement or extensions. >> But each section leads off with the ambiguous phrase *"When the >> application identifies the need for a complete representation of a >> calendar|ordinal date"...* >> So we could just say that Elixir has identified the need for >> representing calendar dates, but not ordinal ones? >> >> On Thursday, February 4, 2021 at 4:03:01 PM UTC-8 José Valim wrote: >> >>> 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 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/c0d90183-befd-411d-9af6-09506584ac95n%40googlegroups.com > > <https://groups.google.com/d/msgid/elixir-lang-core/c0d90183-befd-411d-9af6-09506584ac95n%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/5eaf2a5f-e3be-40e7-bf0c-b5acb4a89ce1n%40googlegroups.com.
