It's not guaranteed that dates for incoming emails will be compliant with Mail.Parsers.RFC2822.to_datetime/1 implementation, which requires forking, patching or a PR to address. If the datetime parser was modular, and either passed in or set via configuration it would allow the end-user the flexibility to handle these cases in their application code. This would be something similar to the optional parser argument in Mail.parse, e.g.
defmodule CustomDateParser do
def to_datetime(<<custom_string_match>> = date_str) do:
# custom parser
end
# fallback to default implementation
def to_datetime(date_str), do: Mail.Parsers.RFC2822.to_datetime(date_str)
end
Mail.parse(email, Mail.Parsers.RFC2822, CustomDateParser)
I'd be happy to contribute such a change if interested.
It's not guaranteed that dates for incoming emails will be compliant with
Mail.Parsers.RFC2822.to_datetime/1
implementation, which requires forking, patching or a PR to address. If the datetime parser was modular, and either passed in or set via configuration it would allow the end-user the flexibility to handle these cases in their application code. This would be something similar to the optional parser argument inMail.parse
, e.g.I'd be happy to contribute such a change if interested.