Proposal: Date.parse_date(String.t(), "%d/%m/%Y") to parse custom date formats defined in strftime

819 views
Skip to first unread message

Bartolomeo

unread,
Sep 13, 2022, 7:26:19 AM9/13/22
to elixir-lang-core
I'd love to have in standard library ability to parse date strings with custom formatters defined by accepted formats Calendar has in place.

I found few libraries that allows me to do this like:
https://elixirforum.com/t/datix-a-date-time-parser-using-calendar-strftime-format-strings/36824
or
https://elixirforum.com/t/date-formats-phoenix-and-ecto/5220/19

To avoid multiple regexes or dependencies to fulfill different client needs it could support formats provided in second arg of ie. `Date.parse_date("21/05/1985", "%d/%m/%Y")`, it would be opposite of `Calendar.strftime` so it would parse a given string, to the date, time or datetime.

Manish sharma

unread,
Sep 13, 2022, 7:32:39 AM9/13/22
to elixir-l...@googlegroups.com

--
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/a60b80ab-22de-4713-b66f-5697f574e3cbn%40googlegroups.com.

Wojtek Mach

unread,
Sep 13, 2022, 7:38:35 AM9/13/22
to elixir-l...@googlegroups.com
Yes, a Calendar.strptime companion to Calendar.strftime is very appealing. Unfortunately there’s no obvious way to create highly-optimzed parser (like the one for ISO8601 is) because it would have to handle e.g. %b (abbreviated month name) along with :abbreviated_month_names option so the input is fairly dynamic which makes it hard to optimize for. For this reason for this particular use case we need to resort to third party libraries. I believe there were previous elixir-lang-core and/or PR discussions about this so you can search for them for more context. Suffice to say I’d love to see this solved in the stdlib too!

Message has been deleted

José Valim

unread,
Sep 13, 2022, 7:52:44 AM9/13/22
to elixir-lang-core
There are also libraries for this purpose, such as https://hex.pm/packages/datix and https://hex.pm/packages/date_time_parser.

On Tue, Sep 13, 2022 at 1:45 PM Bartolomeo <ebart...@gmail.com> wrote:
I noticed most of countries still haven't adopted ISO 8601 https://en.wikipedia.org/wiki/Date_format_by_country
--
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.
Message has been deleted

Bartolomeo

unread,
Sep 13, 2022, 8:37:21 AM9/13/22
to elixir-lang-core
I think using libraries for such tasks would make deps dir too heavy and with reusing of Calendar strftime options Elixir codebase shouldn’t grow much. Currently I use regexes to check allowed dates of birth formats from different clients, eventually we can parse them to dt, I noticed many countries still haven't adopted ISO 8601 https://en.wikipedia.org/wiki/Date_format_by_country, so I just have a feeling it would be consistent and elegant if it would be it in Calendar especially if strftime produces formatted output. For instance %b format from strftime options could be reused to match exact range of abbreviated months from input and I think it should be pretty sufficient for parsing.

Christopher Keele

unread,
Sep 13, 2022, 2:06:59 PM9/13/22
to elixir-lang-core
There is some related discussion on this in this thread. Some relevant take-aways are that even in the context of the most common standard formatting, it is hard™️ to get correct and not trivial to optimize (see: the great amount of effort put into to getting what we have today right). I'm not sure that's how we want the core team to be spending their time compared to other language features, so I definitely prefer keeping the maintenance burden slim here and outsourcing more robust, configurable, quicker-to-iterate parsers in libraries.
Reply all
Reply to author
Forward
0 new messages