[Proposal] Add ability to parse ISO8601 "basic" format

[Stefan Chrobot]

Hi!

Date (and friends) can be formatted using either "basic" or "extended" ISO8601, but parsing is only implemented for the "extended" format.

So one can do:

iex> Date.to_iso8601(~D[2019-07-01]) |> Date.from_iso8601()

{:ok, ~D[2019-07-01]}

but this won't "work":

iex> Date.to_iso8601(~D[2019-07-01], :basic) |> Date.from_iso8601()

{:error, :invalid_format}

Is there any reason for that? Would you accept a PR that adds this feature?

Best,

Stefan

[José Valim]

I am looking forward to the discussion. The only constraint I propose is that the parsing of the basic format would have to be explicit (i.e. you would have to pass the :basic atom to the function).

José Valim

www.plataformatec.com.br

Skype: jv.ptec

Founder and Director of R&D

--
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/172d294d-3a56-42e1-873f-deea0cc0880c%40googlegroups.com.

[Wojtek Mach]

I don't recall any examples at the moment but I remember seeing APIs that return data in the basic format so the proposal sounds good to me.

I agree that the format should be specified explicitly. Given a Date.from_iso8601/2 already exists, the second argument is the calendar (Calendar.ISO by default), the format needs to be the 3rd argument which is a bit unfortunate.

[Allen Madsen]

This might be avoided in the Elixir codebase, not sure. But one clause of the function could specifically check for :basic as the second argument. So, the second argument is :basic or calendar.

def from_iso8601(date, format) when format in [:basic, :extended] do

  from_iso8601(date, format, Calendar.ISO)

end

def from_iso8601(date, calendar) do

  from_iso8601(date, :extended, calendar)

end

Allen Madsen
http://www.allenmadsen.com

On Tue, Aug 6, 2019 at 6:07 AM Wojtek Mach <woj...@wojtekmach.pl> wrote:

I don't recall any examples at the moment but I remember seeing APIs that return data in the basic format so the proposal sounds good to me.

I agree that the format should be specified explicitly. Given a Date.from_iso8601/2 already exists, the second argument is the calendar (Calendar.ISO by default), the format needs to be the 3rd argument which is a bit unfortunate.

--
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/59A9C014-4CD5-40FB-AF33-9CC7C259E691%40wojtekmach.pl.

[Stefan Chrobot]

We could use format as the second argument and make it backwards-compatible using Allen's idea, but it requires at least 4 heads:

  def from_iso8601(date) do
    # :extended + Calendar.ISO
  end

  def from_iso8601(date, format) when format in [:basic, :extended] do

    # format + Calendar.ISO

  end

  def from_iso8601(date, calendar) do

    # :extended + calendar
  end

  def from_iso8601(date, format, calendar) do
    # format + calendar
  end

What do you think? Is it worth it?

Best,

Stefan

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CAK-y3Cs1W8GpSiKPOPh9pr2dwMOYw%2BsoMvRz7Usw71q7RX_DzA%40mail.gmail.com.

[Chris]

What's the harm in just supporting the basic format? I mean, it's in the spec.

To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/CACzMe7YV-Op6QmS__mmLDf9KQ6HqPSou4AynrMsYKQfnn4JeNQ%40mail.gmail.com.

[Chulki Lee]

What about taking both opts (list) and calendar (module)? We may add optional runtime warning when calendar is passed if needed.

The downside is: (probably) it cannot give compile time / dialyzer warning - as we can do with introducing new functions.

[Wojtek Mach]

Another idea is to deprecate `Date.from_iso8601(string, calendar)` in favour of `Date.from_iso8601(string, calendar: calendar)`, and then `:format` becomes just another option.

[Fernando Tapia Rico]

One downside of passing a list of options as a second argument is that it deviates from the other `from_iso8601/2` of other calendar types :)

[Wojtek Mach]

I believe the proposal is about supporting :basic format in all calendar types. All from_iso8601 functions have the same shape right now and if we make a change in one place we should make it remaining too.

[Wojtek Mach]

But yes, I only showed Date.from_iso8601(string, calendar: calendar), I meant to say we’d make this change everywhere. Which also means there would be deprecations everywhere. Thanks for follow-up, this needed clarification.

[Fernando Tapia Rico]

My bad, thanks for the clarification Wojtek!

Looking at other functions of the calendar types, it seems the calendar is always passed as the last argument. 

For reference, here are some functions with an input value, an option, and a calendar as arguments: 

• `DateTime.from_unix(integer, unit \\ :second, calendar \\ Calendar.ISO)`
• `NaiveDateTime.from_erl(tuple, microsecond \\ {0, 0}, calendar \\ Calendar.ISO)` 
• `Time.from_erl(tuple, microsecond \\ {0, 0}, calendar \\ Calendar.ISO)`

I think Stefan's proposal is the closest one to the format of the current function signatures. 

[Kelvin Raffael Stinghen]

> Another idea is to deprecate `Date.from_iso8601(string, calendar)` in favour of `Date.from_iso8601(string, calendar: calendar)`, and then `:format` becomes just another option.

I’m +1 for this one. For optional parameters it is always good what actually that’s optional that it receives. I would even deprecate every `Date.something(date, calendar)` call in favor of that.

Best,
Kelvin Stinghen
kelvin....@me.com

[Dmitry Belyaev]

Getting a value from a keyword definitely costs more then having that value supplied directly as a positional argument. Of course the cost is very small, but why waste when we have a way which doesn't waste.

I suggest a separate function `from_iso8601_short`.

On 9 September 2019 10:07:39 am AEST, Kelvin Raffael Stinghen <kelvin....@gmail.com> wrote:

> Another idea is to deprecate `Date.from_iso8601(string, calendar)` in favour of `Date.from_iso8601(string, calendar: calendar)`, and then `:format` becomes just another option.

I’m +1 for this one. For optional parameters it is always good what actually that’s optional that it receives. I would even deprecate every `Date.something(date, calendar)` call in favor of that.

Best,
Kelvin Stinghen
kelvin....@me.com

On Sep 7, 2019, at 10:10, Wojtek Mach <woj...@wojtekmach.pl> wrote:

Another idea is to deprecate `Date.from_iso8601(string, calendar)` in favour of `Date.from_iso8601(string, calendar: calendar)`, and then `:format` becomes just another option.

--
Kind regards,
Dmitry Belyaev

[Chris]

Again, what's the problem with just silently supporting the basic form, exactly?

--

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/DECB2A72-9D8E-45A7-BF0A-2FA52B7D9887%40gmail.com.