 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / April 2007different timezones causing chaos with rmi
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 > 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 -- >> 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 [quoted text clipped - 3 lines] > 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.  SignatureLew > That doesn't help if one trusts a clock that is inaccurate or not > synchronized with the time one does control. All timestamps should [quoted text clipped - 3 lines] > 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 -- > 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. SignatureLew > > 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 [quoted text clipped - 7 lines] > > -- 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. >> > 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 [quoted text clipped - 16 lines] > 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. > 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 [quoted text clipped - 3 lines] > 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 working on an application deployed in an ASP model using rmi with > > a swing client. I have been running into some problems with dates [quoted text clipped - 9 lines] > converting to and from some human-readable string format, then you > need to be careful. I am serializing a java.util.Date. >> > 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 [quoted text clipped - 11 lines] > > 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. > >> > 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 [quoted text clipped - 16 lines] > 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. > > > 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 [quoted text clipped - 3 lines] > > > hours or lose 3 hours depending on the direction of the > > > translation. ... > 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. Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.