> httpd_util.rfc1123_date/1 encodes a date, I believe this topic is mostly about decoding.
:httpd_util.convert_request_date/1 does decoding, FWIW—see the HTTPDate.to_date_time/2 function in the example above. Plug's implementation also seems good and Elixir-ish. > 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. It might make sense for the HTTP client authors to band together and make a community-blessed http utils lib to start sharing logic between them and arriving on some commonly-useful signatures, which could be introduced as a Plug dependency as well and later progressed to a stdlib inclusion proposal. I still feel like including it in stdlib, especially with some satisfactory-ish erlang tools already available that could take PRs, strays from the spirit of a slim but extensible core. But I'm happy to be proven wrong by an HTTP utils library that becomes so capable as to feel essential! See: development of the :json module. On Fri, Nov 22, 2024 at 3:38 PM 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. > 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 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/FYVQP44UPoI/unsubscribe > . > To unsubscribe from this group and all its topics, send an email to > 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/CAD9kT2QhHgsMRT%3D5fv7n-69zhZBjR%2B_HG8mN0j6j9sU3DZh18Q%40mail.gmail.com.
