Date coercion

[Dave Winer]

Chris, that's the best solution, and there's a long tradition starting with
Unix man pages of documenting bugs.

In this case, imho, the problem would have been neatly solved by simply
adding a Bugs section to the DocServer page explaining that the docs are
incorrect. Document the bug.

Dave


----- Original Message -----
From: "Chris Bunch" <chris at bayswaterfarm.com>
To: <Frontier-Users at userland.com>
Sent: Thursday, May 29, 2003 9:52 AM
Subject: Re: Date coercion


Thanks both -

As you may have guessed I was using date coercion in a try statement to
check user date input into a web form, expecting it to trap the try error
which in fact was never thrown (in the old version). Fortunately this one
was simple enough to workaround. I think we all accept that "the bugs are
part of the way it works", or rather the workarounds are. It would be really
helpful though if there was some repository of known bugs and workarounds
somewhere, and that these could be reflected in DocServer. It would save us
a lot of time -- even though chasing bugs can be a useful learning
experience ;-)

C
____________________________________________


> Since this wasn't actually offlist, this kind of discussion needs to be
> on-list somewhere. Maybe not this one, but some developer list where
changes
> like this can be RFC'd for breakage issues. Now that I'm on the user-side
of
> the fence, I can't afford to have my system go down because of a change
that
> breaks workarounds. In a programming system like Frontier, the bugs are
part
> of the way it works. You can see it in Chris's reaction, he had already
done a
> workaround! Since that verb has been in the language for half a decade, or
> more, it's reasonable to assume it's been worked around elsewhere, perhaps
> even in frontier.root, mainResponder.root or manila.root, where a change
in
> functionality could break every user of the software. We must have some
> insulation from that. In the past I could veto these changes before they
> happened, but now I can't. I want to at least have a *say* in what
happens, to
> be able to warn UserLand of breakage. Dave
>
> ----- Original Message ----- From: "Jake Savin" <jake at userland.com> To:
> <Frontier-Users at userland.com> Sent: Thursday, May 29, 2003 6:02 AM
Subject:
> Re: Date coercion
>
>
> Hi Chris, replying offlist due to political sensitivities...
>
> The fix was already applied to Radio, but unfortunately I had to back off
a
> bit due to potential breakage issues. Rather than make date coercion
always
> fail when an invalid date is passed to date(), I've added an optional
> parameter. If you want to get an error when an invalid date is passed in,
use
> something like this:
>
> date ("foo", true) //will cause an error
>
> Again, this change was applied also to Radio, so you'll have the
functionality
> you need there, as long as you pass in true for the value of the 2nd
> parameter.
>
> Thanks, and sorry the fix was not ideal...
>
> -Jake
>
> On Wednesday, May 28, 2003, at 02:52 PM, Chris Bunch wrote:
>
>> Thanks Jake -
>>
>> Quick work! Now I'll have to delete my workaround. ;-)
>>
>> Will you fix this in Radio as well? That¹s where I usually test things
out.
>>
>> C __________________________________
>>
>>
>>
>>> Hi Chris,
>>>
>>> This was indeed a bug. A fix has been released. To get the fix, update
>>> Frontier.root.
>>>
>>> Thanks, -Jake
>>>
>>> On Wednesday, May 28, 2003, at 11:13 AM, Chris Bunch wrote:
>>>
>>>> According to DocServer (http://docserver.userland.com/coercion/date),
>>>> coercing to a date should fail with an error if the object being
coerced is
>>>> not of the appropriate type.
>>>>
>>>> This appears not to work as billed omm (Mac OS X). Try the following in
>>>> QuickScript:
>>>>
>>>> date("31-Jan-2002")  -- works OK, displays appropriate date string
>>>> date("31-Feb-2002")  -- returns true: does not throw an error
>>>> date("garbage")      -- returns true: does not throw an error
>>>>
>>>> Does DocServer need updating or is this a Bug?
>>>>
>>>
>>>
>>
>
>