OK, I'll check it out. Thanks. ---sam
On 12/19/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
Not sure if this helps but: -) The tacos DatePicker component uses a completely separate javascript package for the actual picker (that is used by a lot of people, even our jira instance) so I would be surprised if it hadn't somehow figured these issues out already. -) The new DropdownDatePicker / DropdownTimePicker components should be fairly bulletproof in this regard as the ibm guy who works on anything i18n related in Dojo ~only~ works on and cares about i18n . The dates/times are transported according to rfc3339 (i think..) so anything appearing in local time should just be for appearances and not for actual client->server sync. On 12/19/06, Sam Gendler <[EMAIL PROTECTED]> wrote: > 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] > > -- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
