different timezones causing chaos with rmi

[epicwinter]

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

 

[Gordon Beaton]

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

--

 

[Lew]

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.

 

[Gordon Beaton]

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

--

 

[epicwinter]

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.

 

[kevin cline]

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.

 

[Lew]

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.

 

[epicwinter]

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.

 

[Karl Uppiano]

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.

 

[Karl Uppiano]

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.

 

[kevin cline]

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.

A java.util.Date does not contain timezone information. The local
timezone is used only when constructing a date via deprecated
methods.

 

[kevin cline]

....
I am serializing a java.util.Date.

How do you know it is "translating itself?" When you convert a Date
to a string without explicitly specifying a timezone, the Date is
converted to a local time in the default timezone. So if you set a
Data to 9:00PM April 26th in US Eastern time, and then print the same
date on a system in US Pacific time, it will be displayed as 6:00 PM
April 26th. But they are the same time, and if you print the timezone
information, you will see that one is
GMT-05:00 and the other is GMT-08:00.