Wojtek and I have the same situation and experience. I created the issue 
after reviewing 
https://github.com/elixir-tesla/tesla/pull/639#discussion_r1853107509 and 
realized that we don't have an established package for this. It sounds like 
httpd_util is the perfect place for this.
Personally, I would love some alignment more than anything. An organization 
like Plug, Phoenix, or anyone dealing with HTTP would own a tiny package 
just for this. I will copy and paste the code for now, but we could share 
more between Reg, Tesla, Plug ... all these HTTP-related things since the 
HTTP spec is one.

In terms of specs, it is similar to httpd_util.rfc1123_date; I need 
clarification on the proposal's format. Do you have a good example I could 
follow? Otherwise, I will trying to find a reference to lean on

On Friday, November 22, 2024 at 4:40:45 PM UTC-5 woj...@wojtekmach.pl wrote:

> 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 <christ...@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-co...@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-co...@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/c625ec4e-ff3d-44b0-ac5b-3cf3deb89b30n%40googlegroups.com.

Reply via email to