The other thing about decoding is that, depending on the needs, you can be
more or less precise. For example, for an HTTP server, I wouldn't mind
parsing the actual weekday.
<<_::3-binary, ", ", day::2-binary, " ", month::3-binary, " ",
year::4-binary, " ",
hour::2-binary, ":", minute::2-binary, ":", second::2-binary, " GMT">> =
"Sat, 17 Apr 2010 14:00:00 GMT"
month =
case month do
"Jan" -> 1
"Feb" -> 2
"Mar" -> 3
"Apr" -> 4
"May" -> 5
"Jun" -> 6
"Jul" -> 7
"Aug" -> 8
"Sep" -> 9
"Oct" -> 10
"Nov" -> 11
"Dec" -> 12
end
DateTime.new!(
Date.new!(String.to_integer(year), month, String.to_integer(day)),
Time.new!(String.to_integer(hour), String.to_integer(minute),
String.to_integer(second))
)
In such cases the implementation is straightforward. The bulk of it is the
mapping of month names to a number. It is so straight-forward I don't think
it justifies an addition to core.
I would actually be more interested in adding a function that makes it
easier to compute elapsed time from now. The implementation in the linked
pull request is not efficient because it is building a current datetime
(from Unix seconds) only to subtract from it, which converts it back to
Unix seconds. We could skip the whole conversion but it is not your fault
you don't, we don't have a decent API for that.
*José Valimhttps://dashbit.co/ <https://dashbit.co/>*
On Fri, Nov 22, 2024 at 10:40 PM Wojtek Mach <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 <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 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
> <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/21A09D12-958F-43C3-BEFC-5834B3B6D106%40wojtekmach.pl
> <https://groups.google.com/d/msgid/elixir-lang-core/21A09D12-958F-43C3-BEFC-5834B3B6D106%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/CAGnRm4KxnNU86DXFPThobON4CRZxW0wteX1uXN2UScm%2BHEXYWw%40mail.gmail.com.
