Invalid encoder for `Date` about elm-export

[charles-cooper]

something like
charles-cooper@d19502c
this requires me to add a line
, "import Exts.Date"
to my elm spec

[charles-cooper]

make that charles-cooper@2a0259b

[charles-cooper]

i guess an issue that needs to be cleared up is that Elm's Date technically corresponds to Haskell's https://hackage.haskell.org/package/time-1.8.0.1/docs/Data-Time-LocalTime.html since it includes a non-timezoned time of day. the two paths i suggest going forward are to only maintain an ElmType instance for Data.Time.LocalTime OR for Data.Time.Calendar.Day, but not both - that way it forces the user to be careful about marshalling to the correct type.

[tekul]

I've just run into this too. In my case I was using a data type with a UTCTime in it. I don't even really need the date value in the client and was happily using the rest of the decoded type on the client side. However I added an update function today and the JSON submitted by the elm encoder wasn't compatible with the original type, so my servant API returns a 400.

Ideally, I'd like to be able to just reuse my Haskell type as it is without being forced into using specific types. I'm not sure what the best option is though.