I am not convinced it belongs in core yet, sorry. But we share excellent and small implementations here you could incorporate when necessary.
*José Valimhttps://dashbit.co/ <https://dashbit.co/>* On Fri, Dec 6, 2024 at 5:59 PM Yordis Prieto <yordis.pri...@gmail.com> wrote: > 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 > <https://groups.google.com/d/msgid/elixir-lang-core/936a1cd6-34cf-4291-b3ea-647d57a2b798n%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/CAGnRm4%2B1bLTT%2Bw1kqkQ0-R8FgJ1JV%2B9epzUUkrEte1EQKDe9tg%40mail.gmail.com.
