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 <christ...@gmail.com> >> 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 <christ...@gmail.com> >>>> 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 <kipc...@gmail.com> 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 <jose....@dashbit.co> 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 >>>>>>>> elixir-lang-co...@googlegroups.com. >>>>>>>> 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 elixir-lang-co...@googlegroups.com. >>>>>>>> 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 elixir-lang-co...@googlegroups.com. >>>>> >>>> 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 elixir-lang-co...@googlegroups.com. >>> >> 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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/c0d90183-befd-411d-9af6-09506584ac95n%40googlegroups.com.
