different client and server timezones == Wicket converter fun?

[Eelco Hillenius <ee...@gmail.com>]

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

Re: different client and server timezones == Wicket converter fun?

[Eelco Hillenius <ee...@gmail.com>]

Looks better than the normal API for sure. We can't use that for
Wicket unfortunately, but it could work for the current project.

Models won't work btw, as models do not distinguish between
conversions for the client and for the server side code. So a
converter makes more sense.

Eelco

On 12/13/06, Igor Vaynberg <ig...@gmail.com> wrote:
> it doesnt
>
> http://joda-time.sourceforge.net/
>
> DateTime now=new DateTime();
> DateTime nowPST=now.withZone(DateTimeZone.forID("PST"));
> DateTime nowEST=now.withZone(DateTimeZone.forID("EST"));
>
> System.out.println(nowPST.hourOfDay());
> System.out.println(nowEST.hourOfDay());
>
> -igor
>
>
> On 12/13/06, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > I'll actually go Igor's path of having model wrappers for this. Darn,
> > why does anything you want to do with dates in Java have to be so
> > awkward all the time.
> >
> > Eelco
> >
>
>

Re: different client and server timezones == Wicket converter fun?

[Igor Vaynberg <ig...@gmail.com>]

it doesnt

http://joda-time.sourceforge.net/

DateTime now=new DateTime();
DateTime nowPST=now.withZone(DateTimeZone.forID("PST"));
DateTime nowEST=now.withZone(DateTimeZone.forID("EST"));

System.out.println(nowPST.hourOfDay());
System.out.println(nowEST.hourOfDay());

-igor


On 12/13/06, Eelco Hillenius <ee...@gmail.com> wrote:
>
> I'll actually go Igor's path of having model wrappers for this. Darn,
> why does anything you want to do with dates in Java have to be so
> awkward all the time.
>
> Eelco
>

Re: different client and server timezones == Wicket converter fun?

[Eelco Hillenius <ee...@gmail.com>]

I'll actually go Igor's path of having model wrappers for this. Darn,
why does anything you want to do with dates in Java have to be so
awkward all the time.

Eelco

Re: different client and server timezones == Wicket converter fun?

[Eelco Hillenius <ee...@gmail.com>]

> when i read it back in its gets converted again so i see 12-12-2006 18:00
> you read it in and you see 12-12-2006 09:00
> Thats fine for appointments but i don't want to have it everytime.
> sometimes the data i type in is really that date (its a literal)
> Example on a website:

Yeah. After waking up this morning I realized that. So the whole
timezone thing should be part of a specialized component/ components
then. Which is less of a head ache I guess.

> "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*."
>
> Do you mean that you had a date (filled in with complete time)
> and then you format it like 12/12 and then convert it back you loose
> everything
> except the 12/12 that you entered?

No, the opposite. I'm inputting at date here before midnight (12/12,
but for the Amsterdam server it is already 12/13), and initialize the
value for the field with the current date. This initial value would be
set to 12/12 (the client's time), but when it is saved, and you don't
want to save the time zone translation as part of it (and
java.util.Date doesn't have this information anyway), you have to
translate this yourself so that 12/13 would be saved. Thing here is
that in many instances you don't care about the time part of a date,
but even though you don't care it will make a difference.

> I have a solution for that i have a Stable DateConverter that works by
> setting the original value
> then apply the string that you want to parse and only the fields that are in
> that string are set
> the rest is kept as it was.

Sounds nice. Can you share?

Eelco

Re: different client and server timezones == Wicket converter fun?

[Johan Compagner <jc...@gmail.com>]

Currently this happens yes?

i input 12-12-2006 18:00 (My Time)
and it gets parsed on the server (in your location -9 hours) and stored like
that.

when you timezone it it will be converted and stored like

12-12-2006 09:00 (your time)

when i read it back in its gets converted again so i see 12-12-2006 18:00
you read it in and you see 12-12-2006 09:00
Thats fine for appointments but i don't want to have it everytime.
sometimes the data i type in is really that date (its a literal)
Example on a website:

Event: Servoy World
location: Amsterdam
from: 12-12-2006 09:00
to: 13-12-2006 18:00

Then the time CAN'T be converted.. Because i already stamp in by giving a
location.
Because if you look at that info then you should see exactly the same output
then when i look at it.
No matter where you are.

also:

"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*."

Do you mean that you had a date (filled in with complete time)
and then you format it like 12/12 and then convert it back you loose
everything
except the 12/12 that you entered?
I have a solution for that i have a Stable DateConverter that works by
setting the original value
then apply the string that you want to parse and only the fields that are in
that string are set
the rest is kept as it was.

johan