<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/xhtml; charset=utf-8">
</head>
<body>
<div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">We’ll keep this in mind. :)</p>
<p dir="auto">On 15 Mar 2017, at 19:58, Will Stanton wrote:</p>
<blockquote style="border-left:2px solid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir="auto">Hello Itai,<br>
<br>
Thanks for your response and its explanations!<br>
<br>
Agreed that comprehension of multiple formats is important since there are a couple common ways of encoding JSON dates!<br>
<br>
Still, ISO 8601 appears pretty often (though I don’t have data on that, Stack Overflow says RFC 7493 I-JSON prefers ISO 8601; <a href="https://tools.ietf.org/html/rfc7493#section-4.3" style="color:#777">https://tools.ietf.org/html/rfc7493#section-4.3</a>), and as other servers might make/handle a lot of JSON produced to/from the API, I think it would be disadvantageous to default to `deferredToDate` (if `deferredToDate` doesn't use the ISO 8601 format).<br>
<br>
As you mention, writers/readers have to agree on their format - my 2¢ is that ISO 8601 would be more common, and so a better default, than a Unix or reference date timestamp.<br>
<br>
Regards,<br>
Will Stanton<br>
<br>
<br>
-—Gracias for the prediction :-)<br>
<br>
<br>
</p>
<blockquote style="border-left:2px solid #777; color:#999; margin:0 0 5px; padding-left:5px; border-left-color:#999"><p dir="auto">On Mar 15, 2017, at 9:53 PM, Itai Ferber <iferber@apple.com> wrote:<br>
<br>
Hi Will,<br>
<br>
Thanks for your comments!<br>
deferredToDate simply uses the default implementation that Date provides — since it is not a primitive type like Int or String and conforms to Codable itself, it will have an implementation of init(from:) and encode(to:). It will have an implementation that makes sense for Date in general, but since a big use-case for JSON lies in talking to external servers which you don't control, allowing for custom date formatting is important.<br>
<br>
To that end, although ISO 8601 may make sense for some applications as the default, it is less efficient to format, encode, decode, and parse than, say, writing out a UNIX timestamp as a Double (or similar). Thus, the default is to allow Date to pick a representation that best suits itself, and if you need customization, you have the option to use it.<br>
<br>
Since Date makes a concrete decision about how to encode, both sides will need to use deferredToDate for compatibility, in the same way that they would have to agree about ISO 8601, or any of the other options.<br>
<br>
HTH!<br>
<br>
— Itai<br>
<br>
P.S. About Xcode autocompletion slowdown, I don't know to be honest, but I can't imagine it would be significant. Only certain types have enc... or dec... and even then, the list of methods isn't that long.</p>
</blockquote></blockquote></div>
</div>
</body>
</html>