You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Sam Gendler <sg...@ideasculptor.com> on 2006/12/20 01:22:06 UTC
DatePicker timezone problem
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: DatePicker timezone problem
Posted by Sam Gendler <sg...@ideasculptor.com>.
OK, I'll check it out. Thanks.
---sam
On 12/19/06, Jesse Kuhnert <jk...@gmail.com> 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 <sg...@ideasculptor.com> 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: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
>
>
> --
> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org
Re: DatePicker timezone problem
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <sg...@ideasculptor.com> 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: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
--
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: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org