I have, what I hope, is a simple question. I’ve a Phoenix web form with a date which is displayed using a JQuery calendar. The problem I have is the date is show as dd/mm/yyyy i.e 02/12/1964. When Phoenix (or more exactly) Ecto tries to parse this it expects the format to be a map of year/month/day. I thought, wrongly that cast would automatically convert from the string date “02/12/1964” to the Elixir format date but I was wrong.
I’m assuming that I have to do some form of conversion but really don’t know where this would go?
Having slept on the problem overnight I’d come to the same conclusion. I suppose my biggest surprise is that this isn’t catered for in standard Phoenix/Ecto as I would have thought it would be a very common situation.
That looks like quite a normal way to write down a date to me. Most hand-written (and by that I mean not produced by a computer system - can be printed) dates I came across in my life with were either dd.mm.yyyy or dd/mm/yyyy.
I remember solving this problem in CakePHP by using its date select with jquery. You just hide the selects and hook them to changes in the calendar. The form submission never knows the difference and as a bonus you get a non-JavaScript fallback.
This is what I do. I have an <input> element of type date or whatever I want it to be, with an is attribute. If no javascript or any issues with javascript it falls back to the ugly but functional native (and often broken, but eh) browser date picker, with javascript then it loads my polymer date element of the full material’y style. The is attribute is awesome and I really really am hating those idiots who are trying to remove it from the standardization process (they don’t care about fallback to older browsers or anything of the sort).