<div dir="ltr">How about calling the new struct &quot;lax-date&quot; or something like that, using the word you&#39;re using below -- I&#39;m not tied to that word, but something that explains more why it is there seems good.<div>
<br></div><div style>Also, I think the documentation needs to be updated to explain the relationship between the racket/date structs and the srfi-19 date structs.</div><div style><br></div><div style>I&#39;m less clear about the other laxness. One other possible thing to consider is that srfi:make-date could do all the same checking that date* does, but if any of it fails (perhaps catch the exn) it creates a lax date. That seems safest. And if we keep pushing a little more, then we can probably get all of the extra functionality of srfi/19 into racket/date and declare srfi/19 to be used only in old code and freeze it completely.</div>
<div style><br></div><div style>Robby</div><div style><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 11, 2013 at 10:57 PM, Asumu Takikawa <span dir="ltr">&lt;<a href="mailto:asumu@ccs.neu.edu" target="_blank">asumu@ccs.neu.edu</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On 2013-01-11 20:58:02 -0600, Robby Findler wrote:<br>
&gt;    I think backwards compatibility here is probably more important than it<br>
&gt;    producing a racket date. Is there some reason not to think so? I believe<br>
&gt;    this library gets used a lot.<br>
<br>
</div>Ok, attached is a second attempt that will use a different struct type<br>
if `string-&gt;date` gets passed a format string that&#39;s missing day, month,<br>
or year. The `make-date` function will also construct one of these lax<br>
types if the day, month, or year fields is #t.  These dates should work<br>
normally, except that racket/date won&#39;t like them.<br>
<br>
This doesn&#39;t attempt to preserve other laxness in srfi/19. For example,<br>
`make-date` previously would not do any error checking of its fields (so<br>
it won&#39;t error until an operation is used which cares about that field).<br>
<br>
It should also support deserialization like Ryan pointed out.<br>
<br>
Cheers,<br>
Asumu<br>
</blockquote></div><br></div>