The manual..... "This function checks against U.S. date formats only. For other date support, see LSDateFormat."
That's the "why" it doesn't like anything other than U.S. date formats. Of course, that MAY be reportable as a bug in the isDate method. Then again, I always convert dates to an internal date format before I do anything else with then anyways. Which is probably why I never had to deal with the "string" issue that is triggering this problem. Gary Menzel On Tue, 30 Nov 2004 15:02:09 +1100, Mike Kear <[EMAIL PROTECTED]> wrote: > On Tue, 30 Nov 2004 14:57:56 +1100, Ryan Sabir <[EMAIL PROTECTED]> wrote: > > Heya Mike, > > > > Isn't > > > > "isdate(parsedatetime(newsitem.pubdate.xmltext))" > > > > a bit redundant, as if CF successfully parsed the string, it will have > > turned it into a date. If you pass something that's not a date in, the > > above function would throw an error. > > > Wel that's the point Ryan. I had newsitem.pubdate.xmltext. I put it > into IsDate(), and figured if it's not a date, it'll just skip over > the CFIF it's in. But it didnt. When it got something that actually > is a date, but not apperently in the format it likes, it threw an > error instead of just returning false so teh CFIF could skip over the > bit of code. > > This only worked when i had both isDate() and parsedatetime(). I'm > not sure why. > > Cheers > Mike Kear > > > > --- > You are currently subscribed to cfaussie as: [EMAIL PROTECTED] > To unsubscribe send a blank email to [EMAIL PROTECTED] > Aussie Macromedia Developers: http://lists.daemon.com.au/ > --- You are currently subscribed to cfaussie as: [email protected] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
