Primitivize time objects by default

[janko]

Since ISO8601 is the standard for time objects, I think we should do this primitivization by default in Yaks. Date/Time objects are pretty common, so I think this change would be friendly to newcomers, and users will almost always want ISO8601.

[plexus]

I disagree. JSON does not standardize how to represent time, so we shouldn't make these assumptions for the user.

[janko]

Yes, JSON itself doesn't standardize time format, but JavaScript does, and since JSON is "JavaScript Object Notation", I was thinking that we could borrow the time format from JavaScript.

I see why you think we shouldn't do this, but maybe we could look at the lack of standard as a hole we can fill in for convenience? I mean, JSON really should have standardized this, they could have just use JavaScript's one. When I was first using Yaks, it took me time to figure out what iso8601 is (after reading it in the readme), and I didn't know if this was what I should use. So with this PR I think we remove those extra mental cycles for newcomers.

[plexus]

I'm sorry but I really want to push back on this. I know it's very common for libraries and frameworks to make these kind of assumptions, and I know it makes things "easier" to some extent. I also think it's a sin against all that is good and true. These kind of assumptions make development the hell hole it is, these kind of assumptions are why we can't have nice things.

Encoding dates out of the box creates the assumption that you'll get a date out on the other end, even though what goes over the wire is a simple JSON string, so you're relying (again) on a non-standard extension/hack in your parser.

If you're going to build a JSON based API you have to be aware of the limitations of JSON. Yaks forces you to be aware that you're opting in to a workaround.

As usual I'm all for improving the docs around this. We can take away developer confusion by educating them, not by paving over important details that imply trade-offs.

[janko]

I respect your opinion. Even though I also don't like a lot of assumptions, I think it's also good not to make to few assumptions, but to find a golden middle. You found your middle, it's just more to the left :)

I updated the README with a short explanation/suggestion. Is that ok?

[plexus]

Yes, that's totally cool <3 It could even have a big warning sign, maybe the README needs a "caveats" section?

I'm a bit of a purist in these things. I've lived through my fair share of WTFs to get to this point. Consider Yaks my humble attempt to hold us all to a higher standard :)

[janko]

I don't think we need to put that in caveats. If you forgot to primitivize, you will get a nice explicit error, and it's all there in the readme.

[plexus]

:+1: hitting the button

[plexus]

And per tradition, a gif for you