On Thu, Jan 8, 2009 at 12:21 PM, Shawn Pearce <[email protected]> wrote: > Has anyone else noticed that java.sql.Date and java.sql.Timestamp throw IAE > if given a date like today, "2009-01-08"? > > Near as I can tell from the emul source, this is due to > Number.__decodeNumberString deciding that a string starting with "0" (so > "08") is octal, setting the radix to 8, and the parse stopping on the "8" > because its not octal.
It's been a long while since I've looked at the code, so I have no idea if this will be useful. Javascript's built-in parseInt takes two arguments: the string to parse and an optional radix specifier. If Number.__decodeNumberString (eventually) delegates to parseInt and passes only one argument, you could patch your copy of GWT to pass two arguments, the second being 10. In other words, if the existing implementation eventually invokes parseInt(stringToParse) you could change it to invoke parseInt(stringToParse, 10) and it should fix your problem. The steps for patching a local copy of GWT have been outlined on this list in the past, so you should be able to find them by searching. On the other hand, if Number.__decodeNumberString doesn't invoke parseInt, you'll probably have to follow wouter's route and suppress leading zeroes. Escaping to Javascript via JSNI to do some regex magic would probably be the easiest way to do that. Ian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
