«

I am working on an application deployed in an ASP model using rmi with
a swing client. I have been running into some problems with dates
when the client is on a different timezone than the server. If the
client is on est and the server runs on pct then when the client
submits a date time it translates itself and so i could either gain 3
hours or lose 3 hours depending on the direction of the
translation.

I realize I can start the client/server on a particular timezone using
the -Duser.timezone property but the users can be all over the place.
Any recommendations on how to handle this type of situation?
thanks

On 23 Apr 2007 17:48:51 -0700, epicwinter wrote:
> I am working on an application deployed in an ASP model using rmi
> with a swing client. I have been running into some problems with
> dates when the client is on a different timezone than the server.

Always represent times internally using UTC. Use the local timezone
only for "user" input and output, converting as close to the user as
possible.

/gordon

--

Gordon Beaton wrote:
> On 23 Apr 2007 17:48:51 -0700, epicwinter wrote:
>> I am working on an application deployed in an ASP model using rmi
>> with a swing client. I have been running into some problems with
>> dates when the client is on a different timezone than the server.
>
> Always represent times internally using UTC. Use the local timezone
> only for "user" input and output, converting as close to the user as
> possible.

That doesn't help if one trusts a clock that is inaccurate or not synchronized
with the time one does control. All timestamps should come from the same
controlled source or else be regarded as completely unreliable.

Generally one cannot make assumptions about times from different clocks when
one doesn't have control over all the clocks.

--
Lew

On Tue, 24 Apr 2007 08:12:38 -0400, Lew wrote:
> That doesn't help if one trusts a clock that is inaccurate or not
> synchronized with the time one does control. All timestamps should
> come from the same controlled source or else be regarded as
> completely unreliable.
>
> Generally one cannot make assumptions about times from different
> clocks when one doesn't have control over all the clocks.

Of course you need some degree of synchronization (through ntp or a
common time source), but exactly how well the components need to be
synchronized ultimately depends on the needs of the application.

However I believe the issue here is not how to achieve that
synchronization or compensate for the lack of it, but how to deal with
different timezones occuring within the application, for example when
the client and server are in different geographic locations. The two
issues are orthogonal.

/gordon

--

On Apr 23, 11:09 pm, Gordon Beaton <n...@for.email> wrote:
> On 23 Apr 2007 17:48:51 -0700, epicwinter wrote:
>
> > I am working on an application deployed in an ASP model using rmi
> > with a swing client. I have been running into some problems with
> > dates when the client is on a different timezone than the server.
>
> Always represent times internally using UTC. Use the local timezone
> only for "user" input and output, converting as close to the user as
> possible.
>
> /gordon
>
> --

Gordon thanks for responding. But my question is how would you
suggest implementing your solution. I use dates all over the software
so I am hoping not to have to write some code every time i work with a
date.

I am not so much concerned about handling issues when users have bad
clocks, that would certainly be nice, but at this point I just want it
to work when the clocks are accurate.

On Apr 23, 7:48 pm, epicwinter <epicwin...@hotmail.com> wrote:
> I am working on an application deployed in an ASP model using rmi with
> a swing client. I have been running into some problems with dates
> when the client is on a different timezone than the server. If the
> client is on est and the server runs on pct then when the client
> submits a date time it translates itself and so i could either gain 3
> hours or lose 3 hours depending on the direction of the
> translation.

What do you mean "translates itself?" How are you passing times from
the client to the server? If you serialize and then deserialize
either a Date or a Calendar you should have no problem. If you are
converting to and from some human-readable string format, then you
need to be careful.

Gordon Beaton wrote:
> However I believe the issue here is not how to achieve that
> synchronization or compensate for the lack of it, but how to deal with
> different timezones occuring within the application, for example when
> the client and server are in different geographic locations. The two
> issues are orthogonal.

Not entirely. If I use only server times, it eliminates the timezone problem
with client times. Therefore, not entirely orthogonal.

--
Lew

On Apr 24, 3:40 pm, kevin cline <kevin.cl...@gmail.com> wrote:
> On Apr 23, 7:48 pm, epicwinter <epicwin...@hotmail.com> wrote:
>
> > I am working on an application deployed in an ASP model using rmi with
> > a swing client. I have been running into some problems with dates
> > when the client is on a different timezone than the server. If the
> > client is on est and the server runs on pct then when the client
> > submits a date time it translates itself and so i could either gain 3
> > hours or lose 3 hours depending on the direction of the
> > translation.
>
> What do you mean "translates itself?" How are you passing times from
> the client to the server? If you serialize and then deserialize
> either a Date or a Calendar you should have no problem. If you are
> converting to and from some human-readable string format, then you
> need to be careful.

I am serializing a java.util.Date.

"epicwinter" <> wrote in message
news: oups.com...
> On Apr 23, 11:09 pm, Gordon Beaton <n...@for.email> wrote:
>> On 23 Apr 2007 17:48:51 -0700, epicwinter wrote:
>>
>> > I am working on an application deployed in an ASP model using rmi
>> > with a swing client. I have been running into some problems with
>> > dates when the client is on a different timezone than the server.
>>
>> Always represent times internally using UTC. Use the local timezone
>> only for "user" input and output, converting as close to the user as
>> possible.
>>
>> /gordon
>>
>> --
>
> Gordon thanks for responding. But my question is how would you
> suggest implementing your solution. I use dates all over the software
> so I am hoping not to have to write some code every time i work with a
> date.
>
> I am not so much concerned about handling issues when users have bad
> clocks, that would certainly be nice, but at this point I just want it
> to work when the clocks are accurate.

You should only convert to and from local time at the client UI. Everything
should be UTC (as long milliseconds) internally - that's what you should be
sending over RMI. Most of Java's time and calendar conversion routines work
that way. If you work with them as they were designed, it is almost a non
issue. But the timezones do need to be set correctly on all machines.

"epicwinter" <> wrote in message
news: oups.com...
> On Apr 24, 3:40 pm, kevin cline <kevin.cl...@gmail.com> wrote:
>> On Apr 23, 7:48 pm, epicwinter <epicwin...@hotmail.com> wrote:
>>
>> > I am working on an application deployed in an ASP model using rmi with
>> > a swing client. I have been running into some problems with dates
>> > when the client is on a different timezone than the server. If the
>> > client is on est and the server runs on pct then when the client
>> > submits a date time it translates itself and so i could either gain 3
>> > hours or lose 3 hours depending on the direction of the
>> > translation.
>>
>> What do you mean "translates itself?" How are you passing times from
>> the client to the server? If you serialize and then deserialize
>> either a Date or a Calendar you should have no problem. If you are
>> converting to and from some human-readable string format, then you
>> need to be careful.
>
> I am serializing a java.util.Date.

You should not do that. java.util.Date is initialized with the local time
zone. Send the UTC time in milliseconds as a long instead. Use that to
reconstitute a new date at the other end. The timezone conversion will be
done automatically for you, including daylight saving time, leap years, etc.