I think it is a firefox bug, because if we execute alert(new Date()) we get something like Sun Oct 14 2007 14:49:34 GMT-0200, but when execute alert(new Date( (new Date()).setHours(0) )) we get Sat Oct 13 2007 23:50:30 GMT-0300 (Hora oficial do Brasil)...

i tryed to overhide this function (clearTime) to avoid it, but without sucess...

I think it is a firefox bug, because if we execute alert(new Date()) we get something like Sun Oct 14 2007 14:49:34 GMT-0200, but when execute alert(new Date( (new Date()).setHours(0) )) we get Sat Oct 13 2007 23:50:30 GMT-0300 (Hora oficial do Brasil)...

i tryed to overhide this function (clearTime) to avoid it, but without sucess...

obs.: i set up my system date to 10/14/2007

Well, I don't think it is a FF bug.
In the DatePicker code, Ext uses getTime function that, according with the mozilla javascript documentation, "returns the numeric value corresponding to the time for the specified date according to universal time". So DatePicker should use UTC time everywhere in the code.

Here it is a patch that could solve the problem (there's still an issue with the selected day, but works in FF 2, IE 6 and Safari 3):

I don't think the proposed patch of converting the values to UTC is the answer.

I'm guessing you're pulling the date from a database, so I have a hunch the root of the problem has something to do with the timezone of the date in the database, not matching the timezone of the browser.

For example, the date in the database might be stored as UTC, but when rendered to the browser, the DateField/DatePicker is using the browsers local timezone settings.

Once the date is pulled into the DateField/DatePicker, the .clearTime() function comes in for the final kill. For example if the timezone of the date in the database is even one hour different (less) than the browsers timezone there's going to be trouble.

A date value stored in the database as 5-Jun-2008 @ 00:00 UTC, then sent to browser (-1 hour timezone) may be converted by the browser to 4-Jun-2008 @ 23:00. Once passed through .clearTime(), the date will be changed to 4-Jun-2008 @ 00:00. Hence, the date being "off-by-one".

If your database is storing date values as UTC, and your browser is set to Pacific Standard Time (PST -800), 5-Jun-2008 @ 00:00 UTC, may result in a date of 4-Jun-2008 @ 16:00 being rendered in the browser.

To verify, I'd need someone to post a full sample with the JSON/config, confirmation of browser's local/timezone and the date value coming stored in the server.

There might be answer with converting the dates to UTC, although confusion is sure to happen because users are expecting the DateField value to be relative to their machine.

I could be wrong, but I'm certainly available to step through the problem with anyone willing to troubleshoot.

Well, maybe I'm wrong, but I don't think Ext library should be aware of how dates are saved into the database, 'cause if I want to save dates as strings, then Ext should perform automatic conversions too.
I think here we have a problem into the view layer, into the component. If the code of the component use a UTC method and then, after few lines, use a non UTC method, then there is a problem. And I can see this problem here on my browsers (IE, FF and Safari) every time I try to choose a date that is in a different time zone from my current one (i.e. if I'm in CET and I choose a CEST date and vice versa), and not while reading a date from the database. I simply click on a date in the picker, and I get another one in the text field.

Since I have to deploy an Ext application for production, I need to deploy a working one. This patch is probably a bad workaround of the problem, but it works. If there is a better solution coming from ext developers, then I'll be happy for that...in the meanwhile I'll patch Datepicker.js every svn update.