Howdy,
I have an interesting problem here. However basic it may sound, it's
new to me, as I haven't had to deal much with different time zones
before. When clients and servers are in different time zones, working
with dates is funny. For instance, the servers of the project I'm
working on are in NYC, while most of our testers, including yours
truly live on the west coast of the US, 3 hours behind. If you work
with dates with time info, you'll notice quite quickly that when you
create a foobar item that has a time stamp field (say created) in it,
that you actually made that item 3 hours ahead. Of course, the thing
to do here is to get the client's time zone, and use that for
displaying the 'corrected' date.
When you don't use times, it's not as obvious, which is probably the
reason not many/ none people complain about it. However, if I'm within
three hours before midnight, those foobar items will be made the next
day according to my user interface without correction.
To make this long story short, I think this is something we could and
should solve in a generic fashion in Wicket. Our DateToStringConverter
would look like this:
/**
* @see
wicket.util.convert.ITypeConverter#convert(java.lang.Object,java.util.Locale)
*/
public Object convert(final Object value, Locale locale)
{
Date date = (Date)value;
DateFormat dateFormat = getDateFormat(locale);
if (dateFormat != null)
{
TimeZone timeZone = getClientTimeZone();
if (timeZone != null)
{
dateFormat.setTimeZone(timeZone);
}
return dateFormat.format(value);
}
return date.toString();
}
/**
* Gets the client's time zone.
*
* @return The client's time zone or null
*/
protected TimeZone getClientTimeZone()
{
ClientInfo info = Session.get().getClientInfo();
if (info instanceof WebClientInfo)
{
return
((WebClientInfo)info).getProperties().getTimeZone();
}
return null;
}
I tested that, and that seems to work as supposed to. The translation
from input to local time (using the server's timezone) is a bit more
tricky however. Keep an example in mind of the server being in the
next day compared to the client, say client 12/12 and server 12/13,
and a user interface with a date(text) field that is initialized with
now (new Date()).
1) Using the first part of the fix, the date in the text field will be
12/12. This of course should be converted on the server side to be
12/13 for as far as the server is concerned, that's the date corrected
for the time zone.
2) The first nasty thing is that pulling 12/12 through a date form,
will give you a date initialized with 12/12 *but also with all time
fields zero-d out*.
3) So the next step would be to fill in the time fields (use a temp
calendar for instance) in such a way that we would have the client's
time.
4) When we have that, we should apply the time zone correction, which
in our example would have to result in three hours added, and the date
thus jumping to the next day.
I got to 3) but I'm tired and ready for bed now, and furthermore I
wanted to hear what you're thinking of all this. My two questions:
1) Does everyone agree this fix should be applied directly to the date
formatters? I *do* think we should as it doesn't break any clients in
the same time zone or situations where there is none known, but also
because the current situation, though subtle and probably not a
problem for many people, is just wrong.
2) Who wants to implement the DateConverter (from string input to the
date). It would help me tremendously if someone could give it a go
while I'm dreaming of other things.
Thanks,
Eelco
