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.
To view this discussion visit 
https://groups.google.com/d/msgid/elixir-lang-core/F604B657-E980-45F1-9297-DF409E4E3BAC%40wojtekmach.pl.

Reply via email to