Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Invalid encoder for Date #38

Open
charles-cooper opened this issue Apr 11, 2017 · 4 comments
Open

Invalid encoder for Date #38

charles-cooper opened this issue Apr 11, 2017 · 4 comments

Comments

@charles-cooper
Copy link

I think the JSON encoder for Date is not compatible with Aeson. It uses the toString method which produces

(elm repl)
> toString (Date.fromTime 1491938767000)
"<Tue Apr 11 2017 12:26:07 GMT-0700 (PDT)>" : String

but aeson is expecting an ISO8601 date
https://hackage.haskell.org/package/aeson-1.1.1.0/src/Data/Aeson/Parser/Time.hs#day

(ghci)
Prelude> :set -XOverloadedStrings
Prelude> import Data.Time.Calendar as D
Prelude D> import Data.Aeson as A
Prelude D A> fmap D.toGregorian (A.decode "\"2017-01-01\"")
Just (2017,1,1)

I'm happy to submit a pull request.

@charles-cooper
Copy link
Author

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

@charles-cooper
Copy link
Author

make that charles-cooper@2a0259b

@charles-cooper
Copy link
Author

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
Copy link

tekul commented Jul 13, 2017

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants