I think the fact that we support emitting basic is very useful for things like files with timestamps in names; to me the most harmonious thing would be supporting in the parser as well via the flag mechanism you've proposed. I may take a stab at it but I think a separate PR is the best way to go in implementing it, so any surprising considerations can be discussed separately.
On Thu, Feb 4, 2021 at 11:44 PM José Valim <[email protected]> wrote: > 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 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/CAGnRm4%2BgKCKEabwr6DnGj9AxcUhugW%3DpT9%2B-hq_XrEatyAM9Ow%40mail.gmail.com > <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2BgKCKEabwr6DnGj9AxcUhugW%3DpT9%2B-hq_XrEatyAM9Ow%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/CAD9kT2T5O-GjxTY_i_bj1-wRqtLcOkH4xiZoYzuQfcu4W5a0jw%40mail.gmail.com.
