To complement what Kip says, the ISO standard also focuses a lot on what is
agreed between parties. For example, ISO says you can submit a date as
2021-01, as long as both parties agree on that. Does it mean we should
support 2021-01 on Elixir out of the box?
There is also the argument in that, if we parse 2021-034 by default, what
happens when the user explicitly does not want to support this format? For
example, my invoices follow precisely the YYYY-NNN format, and if someone
wrote a code that detects between invoice numbers and dates, you may now
accidentally parse invoices as dates.
So if we want to support this, maybe we should tag it accordingly:
Date.from_iso8601("2020-323", :ordinal)
That can also be the way to support the :basic format, which we currently
do not support.
On Thu, Feb 4, 2021 at 2:58 AM Christopher Keele <[email protected]>
wrote:
> > I think it's important to be careful on the scope. The ISO8601 spec is
> vast (I am implementing a new lib that implements the whole thing and its a
> huge task).
>
> This is a good point. I'm carefully pulling this particular thread, trying
> not to unweave the whole tapestry, because it does seem inline with what
> the stdlib tries to accommodate today:
>
> - We do not handle century dates, decade dates, etc
> - We do not handle implicit or "relative" dates
> - We do not handle week references
>
> Generally, we only handle explicit year/month/day references to precise
> calendar dates in string parsing. Ordinal dates are an edge case here: they
> can be trivially converted to such with the current calendar protocol.
>
> My cursory reading of the ISO8601 spec suggests that this is possibly the
> only "advanced" date descriptor that is trivial to implement against the
> calendar protocol today, but I'd appreciate your insight into that! I could
> have easily overlooked some features; and by implementing ordinal dates, I
> may be opening a can of worms definitely better left to a library.
> On Wednesday, February 3, 2021 at 5:45:22 PM UTC-8 Kip wrote:
>
>> I think its important to be careful on the scope. The ISO8601 spec is
>> vast (I am implementing a new lib that implements the whole thing and its a
>> huge task) .
>>
>> > "I think we should probably consider this a bug, and fix functions
>> which parse ISO-8601 dates so that they support what's allowed in the
>> ISO-8601 spec". This is not a realistic goal for Elixir core I think.
>>
>> Ordinal dates, explicit and implicit forms of dates, century dates,
>> decade dates, ..... thats a lot of surface area for maintenance that in the
>> spirit of Elixir probably lies better in an external library if required.
>>
>>
>> On Thursday, February 4, 2021 at 9:30:32 AM UTC+8 [email protected]
>> wrote:
>>
>>> WIP PR available here: https://github.com/elixir-lang/elixir/pull/10687
>>>
>>> I've proved the concept, but want to step back and solicit feedback, get
>>> some discussion going on explicit points I call out in the PR, and think of
>>> ways to clean the implementation up a little.
>>>
>>> On Wednesday, February 3, 2021 at 2:53:23 PM UTC-8 [email protected] wrote:
>>>
>>>> +1
>>>>
>>>> On Wed, Feb 3, 2021 at 2:54 PM Christopher Keele <[email protected]>
>>>> wrote:
>>>>
>>>>> As observed by @ryanbigg <https://twitter.com/ryanbigg> on Twitter
>>>>> <https://twitter.com/ryanbigg/status/1356847900035190786>,
>>>>> *"2021-034"* is a valid ISO 8601 date.
>>>>>
>>>>> Specifically, it is an ordinal date
>>>>> <https://en.wikipedia.org/wiki/Ordinal_date> descriptor of the format
>>>>> YYYY-DDD. Unlike some of the more exotic ISO 8601 formats, like naming a
>>>>> week of the year or a day+month without a year; it does fully describe a
>>>>> single date in time.
>>>>>
>>>>> As Ryan observes, Ruby supports parsing ordinal date strings but
>>>>> Elixir does not. Is this something we'd want to add? Honestly the correct
>>>>> behaviour here is almost more surprising to me than our lack of support
>>>>> for
>>>>> it, but I wanted to field a discussion about it.
>>>>>
>>>>> --
>>>>>
>>>> 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/51e44339-31aa-4ec6-93c8-3ca0f7901926n%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/elixir-lang-core/51e44339-31aa-4ec6-93c8-3ca0f7901926n%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Regards,
>>>> Bruce Tate
>>>> CEO
>>>>
>>>>
>>>> <https://bowtie.mailbutler.io/tracking/hit/f8218219-d2a8-4de4-9fef-1cdde6e723f6/c7c97460-016e-45fb-a4ab-0a70318c7b97>
>>>>
>>>> Groxio, LLC.
>>>> 512.799.9366 <(512)%20799-9366>
>>>> [email protected]
>>>> grox.io
>>>>
>>> --
> 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/84f61e39-f261-43dd-9dd2-48cf9bcb4937n%40googlegroups.com
> <https://groups.google.com/d/msgid/elixir-lang-core/84f61e39-f261-43dd-9dd2-48cf9bcb4937n%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%2BxAiOwff4FtdJoVormDLh8ZZ%3Dt4iOOMLqicH97uvJsqQ%40mail.gmail.com.
