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.
