I like the direction of the PR a lot. My only remaining question is if we should do anything about the fact to_iso8601 supports basic but we don't support basic on parsing. Our options are:
1. Keep as is 2. Parse basic 3. Deprecate basic to_iso8601 I have already fixed master to raise if someone is trying to convert a date with a negative year to basic. On Fri, Feb 5, 2021 at 2:20 AM Christopher Keele <[email protected]> wrote: > WIP PR here <https://github.com/elixir-lang/elixir/pull/10689>. Wanted to > solicit feedback on some of the language early, specifically these bits > <https://github.com/elixir-lang/elixir/pull/10689/files#diff-dcf96a67c40fc65bbe2dcd9a4d259b5da5a3b9a82372846f50b0a3d562fc0a1bR13-R49>. > Will resume work on it a little later! > > On Thursday, February 4, 2021 at 4:30:43 PM UTC-8 Christopher Keele wrote: > >> 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/c7924190-eab0-4db4-a82e-02203d43e23en%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/c7924190-eab0-4db4-a82e-02203d43e23en%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/CAGnRm4%2BgKCKEabwr6DnGj9AxcUhugW%3DpT9%2B-hq_XrEatyAM9Ow%40mail.gmail.com.
