Wojtek Mach

@abitdodgy there would be minor changes, yes, but not much: 1. the app is already broken up into domain and web part, similarly how `mix phx.new --umbrella` would do it...

What OS do you use? Seems like your Erlang installation hasnt been compiled with ssl so I’d start there, even though its not needed for this particular project it will...

are you using official docker image for elixir? I can check it after the weekend, in the meantime I'd recommend to find help elsewhere: elixirforum, slack, irc. Also, check if...

Thank you for pointing this out, I’ll definitely move forward with this.

I'm worried that introducing +1 arity version my come back to bite us later, for whatever reason we'd add `opts \\ []` at the end and then we'd have "conflicting"...

Since we support them in new/2, I think we should also support passing dates and so we may as well allow `%Date.Range{}`, these should be equivalent: ```elixir CalendarInterval.new({~D[2020-01-01], ~D[2020-12-31]}, :minute)...

Thanks Kip! > Overall, my opinion would be: Do you mean these in the context of calendar_interval or stdlib or both? > 1. Allow all date/time structures Agreed. > 2....

> We have NaiveDateTime.from_erl/2 and from_iso8601/1 but not from_date. Do you sense whether a proposal to add that would be considered? Good question. Today we can do: `NaiveDateTime.new(date, ~T[00:00:00])` (there's...

tl;dr we're currently, arguably, breaking the enumerable contract, see this discrepancy: ```elixir iex> ~D[2020-01-01] in ~I"2020-01/12" true iex> Enum.filter(~I"2020-01/12", & &1 == ~D[2020-01-01]) [] ``` the change would be to...

Thank you for the PR. Could you talk more about your use case? What's the before/after of your application code after this change? What are other reasonable periods folks could...