Hey folks, any resolution you would like to see here? Not sure what I should do next.
On Friday, November 22, 2024 at 6:26:44 PM UTC-5 Yordis Prieto wrote: > I am with Wojtek on this one > > On Friday, November 22, 2024 at 6:04:59 PM UTC-5 woj...@wojtekmach.pl > wrote: > >> FWIW here’s Req implementation for http date encoding/decoding: >> https://github.com/wojtekmach/req/blob/5bfbccc698f7639b890d8829cefb5a12903eece0/lib/req/utils.ex#L251:L325. >> >> I’m sure decoding can be significantly improved but I’d expect it to be >> reasonably fast already. >> >> Personally I would not create a package for <100 LOC that can be easily >> copy pasted around but that’s just me. For this reason while I wouldn’t >> mind having it in core it’s fine it isn’t. (I’d guess for better or worse, >> mostly worse lol, it is second most commonly used format, after iso8601, >> which obviously _is_ in core.) >> >> Regarding a format for proposals I don’t believe there’s one. What I like >> to do, with varying success, is to send a good old usage examples like: >> >> iex> Foo.bar() >> :baz >> >> I think that goes a long way. >> >> Do you argue for adding it to Calendar or NaiveDateTime, or DateTime. >> Should it be called parse_http_date or parse_rfc1123 or something else? Why >> this and not that? Should we encode as well? If you want to add something I >> think the onus is on you to try answering those questions. >> >> On 22 Nov 2024, at 23:30, Yordis Prieto <yordis...@gmail.com> wrote: >> >> 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-co...@googlegroups.com. >> >> To view this discussion visit >> https://groups.google.com/d/msgid/elixir-lang-core/c625ec4e-ff3d-44b0-ac5b-3cf3deb89b30n%40googlegroups.com >> >> <https://groups.google.com/d/msgid/elixir-lang-core/c625ec4e-ff3d-44b0-ac5b-3cf3deb89b30n%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/936a1cd6-34cf-4291-b3ea-647d57a2b798n%40googlegroups.com.
