I'm only just starting to look into this problem, so I'll likely post more detail in future emails, but it looks as though there is a problem with the DatePicker component when the server and the client are not in the same timezone. Internally, the Calendar javascript object that is defined in DatePIcker.js uses an offset from Jan 1, 1970 GMT to store the date, which is fine, since it is independant of timezone. The visual calendar element then displays with the selected date computed including the local zimezone on the browser machine. This wouldn't by itself, be a huge problem, except that the initial value in the text box is displayed according to the timezone on the server. So if my server is in GMT+1 and it creates a DatePicker using a date of Dec 20, 2006, the DatePicker text box will display 12/20/2006 (or whatever the appropriate format is). When I click on the calendar icon from a browser in GMT-8, however, the resulting calendar actually displays with Dec 19 selected, even though the text box shows Dec 20. If I print the value of the date in a js debug statement, it will actually show 15:00 on Dec 19, which is 9 hours back from 00:00 on Dec 20. If I then select Dec 20 on the calendar, the text box will continue to display Dec 20, but now there will be 24 hours added to the associated date object, meaning it will display 15:00 on Dec 20, which isn't really what I wanted (prefer 00:00 on Dec 20).
If the component is going to compute timezone offsets, it should continue to compute them with newly selected dates, rather than just with the default values. Also, the original value needs to have the same computation applied to it. More importantly, I don't really think it should be doing timezone computations at all unless I ask it to (and I don't see anything obvious in the javascript that would let me toggle it). Finally, since it is a calendar object that does not provide a mechanism for setting time, it should be truncating values to only include the date. Does anyone know a way that I can use the DatePicker with 'raw' values, meaning it should convert the supplied date to unixtime within the browser time zone, rather than on the server? This is causing me big headaches since I've got users in 6 widely disparate timezones and asking them all to set their desktop machines to use GMT just isn't reasonable. Does the tacos DatePicker behave differently in this regard? In our case, it is understood that all dates are server time, so it is a problem that the component is converting to local time. --sam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
