Oops, the Plug link I sent is obviously about encoding to that format not decoding from it. It’s late here, sorry about that.
> On 22 Nov 2024, at 22:38, Wojtek Mach <woj...@wojtekmach.pl> wrote: > > httpd_util.rfc1123_date/1 encodes a date, I believe this topic is mostly > about decoding. > > As an http client author I’m +1 for this because it occasionally comes up in > the type of work I end up doing. > > That being said, I think it’d be more productive to have an actual proposal, > what would be the function name, args, and returns values and consideration > for how it fits within the standard library. > > As an aside, my recommendation would be to instead of bringing in a > dependency, copy-pasting this from Plug > https://github.com/elixir-plug/plug/blob/v1.16.1/lib/plug/conn/cookies.ex#L99:L139. > This, though, might be the primary reason _not_ to add this, it’s easy to > copy-paste a rock solid implementation from an authoritative source in Plug. > >> On 22 Nov 2024, at 22:15, Christopher Keele <christheke...@gmail.com> wrote: >> >> I believe such an Elixir-friendly tool would be useful, but does not belong >> in the Elixir language itself. >> >> In the spirit of a slim but extensible core, functionality and especially >> structs in Elixir stdlib tend to be limited to: >> >> - Things useful to any domain, that can only be realized optimally in the >> language itself >> - Things required by the language tooling itself >> >> For example, you see general things like Range parsing/structs in stdlib >> because their membership tests work with guards and the in operator, so the >> language itself has to be able to operate on them. And you see things like >> the URI parsing and semantic Version structs in the stdlib because they are >> required for mix to be able to fetch libraries and resolve version >> constraints. >> >> If Elixir needed to deal with this date format to work, or if they were more >> general-purpose, there'd be a stronger case for inclusion. As it, it >> probably belongs in one of the general-purpose HTTP handling libraries as a >> dependency. >> >> On the other hand, you can always go pouring through the erlang stdlib's >> much more kitchen-sinky set of tools for these sorts of things to see if >> functions that accomplish what you want are already available to you from >> erlang itself, without extra dependencies. For example, I knew that erlang >> comes with a pretty robust http server/client implementation. I remembered >> that it has a module called :httpc, so I found the docs for the application >> that contains it, :inets. I noticed an :http_util module in there, and it >> seems to have the functionality you want. For Elixir compatibility, you just >> need to translate between erlang and Elixir, something like: >> >> defmodule HTTPDate do >> def now(calendar \\ Calendar.ISO) do >> calendar |> DateTime.utc_now() |> from_date_time() >> end >> >> def from_date_time(date_time = %DateTime{}) when date_time.utc_offset == 0 >> do >> { >> {date_time.year, date_time.month, date_time.day}, >> {date_time.hour, date_time.minute, date_time.second} >> } >> |> :httpd_util.rfc1123_date() >> end >> >> def from_date_time(other), do: raise("expected a DateTime in UTC (GMT), >> got: #{inspect(other)}") >> >> def to_date_time(string, calendar \\ Calendar.ISO) do >> with {{year, month, day}, {hour, minute, second}} <- >> :httpd_util.convert_request_date(string), >> {:ok, date} <- Date.new(year, month, day, calendar), >> {:ok, time} <- Time.new(hour, minute, second, {0, 0}, calendar) do >> DateTime.new(date, time, "Etc/UTC") >> else >> # Normalize :httpd_util.convert_request_date errors >> :bad_date -> {:error, :invalid_date} >> # Date/Time/DateTime.new errors >> {:error, reason} -> {:error, reason} >> end >> end >> end >> >> On Thursday, November 21, 2024 at 6:18:50 PM UTC-6 yordis...@gmail.com wrote: >>> I came across a PR that required parsing >>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Date, so the >>> person reached out for a third-party library. >>> >>> I wonder if Elixir should handle parsing HTTP Date or allow the >>> construction of a Date using the day name (Mon, Tue ...), month name (Jan, >>> Feb), and other formatting from HTTP Date. >> >> >> -- >> 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-core+unsubscr...@googlegroups.com >> <mailto:elixir-lang-core+unsubscr...@googlegroups.com>. >> To view this discussion visit >> https://groups.google.com/d/msgid/elixir-lang-core/c17fcb61-9517-4fef-9f88-8290d36b3799n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/c17fcb61-9517-4fef-9f88-8290d36b3799n%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 elixir-lang-core+unsubscr...@googlegroups.com > <mailto:elixir-lang-core+unsubscr...@googlegroups.com>. > To view this discussion visit > https://groups.google.com/d/msgid/elixir-lang-core/F604B657-E980-45F1-9297-DF409E4E3BAC%40wojtekmach.pl > > <https://groups.google.com/d/msgid/elixir-lang-core/F604B657-E980-45F1-9297-DF409E4E3BAC%40wojtekmach.pl?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 elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion visit https://groups.google.com/d/msgid/elixir-lang-core/21A09D12-958F-43C3-BEFC-5834B3B6D106%40wojtekmach.pl.
