Date Time
[208 byte] By [Anna78a] at [2007-11-27 7:49:03] 
I am working as backend side on the weblogic 8.1. Our client sends us activity date as 01/04/2007 23:59:58. However we are getting 22:59:58 (one hour back). What can be the reason for it?
Different clock settings? Different timezones?
quittea at 2007-7-12 19:29:56 >
Where can I check it?
Anna78a at 2007-7-12 19:29:56 >
a) System settings (clock, locale)b) Java system properties (used or configured Locale/TimeZone, Locale.getDefault() )How do you handle timestamp transfer? How do you display/read/store values?
quittea at 2007-7-12 19:29:56 >
Our client just sends it hard coded. Where in the weblogic configuration can I check the time setting?
Anna78a at 2007-7-12 19:29:56 >
Can this problem be related to DST?
Anna78a at 2007-7-12 19:29:56 >
What do you mean, hardcoded? Do they send you a String?
CeciNEstPasUnProgrammeura at 2007-7-12 19:29:56 >
No, they send me Date, but they put there hardcoded value... It seems to be configuration issue or something, because the mismatch appear only in one environment. And I can not configure out what the problem is.. Please help...
Anna78a at 2007-7-12 19:29:56 >
> Can this problem be related to DST?Possible. You should check the clock and locale settings of the machine where you get an unexpected date/time string. Java settings basically rely on system settings but _can_ be reconfigured.
quittea at 2007-7-12 19:29:56 >
I see.. How can I check clock and locale settings of the machine? I mean technically.. Where can I see it?
Anna78a at 2007-7-12 19:29:56 >
> I see.. How can I check clock and locale settings of> the machine? I mean technically.. Where can I see it?Grab your favorite OS's manual...You didn't even tell us what kind of machine it is. How should we know?
CeciNEstPasUnProgrammeura at 2007-7-12 19:29:56 >
Yep.. u right.. It is HP Unix. Java version "1.4.2.11". BEA_HOME=/opt/weblogic81sp5
Anna78a at 2007-7-12 19:29:56 >
I recommend to ask your server administrator. What you can do is check what you get for TimeZone.getDefault().
quittea at 2007-7-12 19:29:56 >
$ timezone
corlettka at 2007-7-12 19:29:56 >
According to what I checked timezone on my unix machine is "Asia/Jerusalem". To what should I compare this timezone? To the time zone on the client machine? Our client is invoking EJB API through RMI...
Anna78a at 2007-7-12 19:29:56 >
Any ideas? What can cause to one hour gap in the time?
Anna78a at 2007-7-21 22:22:10 >
> Any ideas? What can cause to one hour gap in the time?See Reply #1.
DrClapa at 2007-7-21 22:22:10 >
> > Any ideas? What can cause to one hour gap in the> time?> > See Reply #1.StackOverflowError ;o)~
yawmarka at 2007-7-21 22:22:10 >
> According to what I checked timezone on my unix
> machine is "Asia/Jerusalem". To what should I compare
> this timezone? To the time zone on the client
> machine?
> Our client is invoking EJB API through RMI...
Okay, he's sending you a java.util.Date or some subclass, right? And it's displaying differently on his side than on yours? If you can change the format of the display on both ends to include TZ, you'll most likely see that yours shows a TZ that's an hour different from his. Barring that get the administrator on the server side to tell you what TZ that box is set to, and check what the TZ on your side is set to.
jverda at 2007-7-21 22:22:10 >
Thanks for all the replies I got.
I thougth about different reason for the time mismatch. Our Client is working on HP java version "1.4.2.08". Backend is java version "1.4.2.11". I know that DST latest changes is supported from java version "1.4.2.11". The date that I am getting in the input is 1 Apr 2007. I read on the Sun site that applications running on an older JRE may report incorrect time from March 11, 2007 through April 2, 2007 and from October 29, 2007 through November 4, 2007.
What do you think - can it be the reason for the mismatch?
Anna78a at 2007-7-21 22:22:10 >
Did the problem occur during one of those time periods?
jverda at 2007-7-21 22:22:10 >
> applications running on an older JRE may report incorrect time from
> March 11, 2007 through April 2, 2007 and from October 29, 2007
> through November 4, 2007.
This specifically applies to North American time zones. Not to Asia/Jerusalem. (Although I understand that Israel's handling of time zones is even more chaotic.)
DrClapa at 2007-7-21 22:22:10 >
> > applications running on an older JRE may report
> incorrect time from
> > March 11, 2007 through April 2, 2007 and from
> October 29, 2007
> > through November 4, 2007.
>
> This specifically applies to North American time
> zones. Not to Asia/Jerusalem. (Although I understand
> that Israel's handling of time zones is even more
> chaotic.)
Good point.
@OP: Have you looked at what I suggested in reply 18?
jverda at 2007-7-21 22:22:10 >
> > applications running on an older JRE may report
> incorrect time from
> > March 11, 2007 through April 2, 2007 and from
> October 29, 2007
> > through November 4, 2007.
>
> This specifically applies to North American time
> zones. Not to Asia/Jerusalem. (Although I understand
> that Israel's handling of time zones is even more
> chaotic.)
Good point.
@OP: Have you looked at what I suggested in reply 18?
On the other hand, if the TZs there are chaotic, it might be that there have either been changes to the rules recently or refinements/bugfixes in the OS. (Was this two different verions of the same OS we're talking about? I've lost track.)
jverda at 2007-7-21 22:22:10 >
yes, there were diffent jvm versions on the client (1.4.2.8) and server (1.4.2.11) side. The mismatch occured at 1 Apr 07.
Anna78a at 2007-7-21 22:22:10 >
The best educated guess I can make is that the two versions have different DST rules. Perhaps the newer version corrected a bug in the older version, or perhaps, if the TZs are "chaotic" there as someone said, the rules changed around the release of 1.4.2.11, and that was the first version to have the new rules.
Is 1 Apr. 07 when DST kicks in?
You can do something like this:
In both the old version and the new version, run a little test program that creates a Calendar whose time is shortly before the DST transition, (say an hour before) and then add() a couple of hours to it. Observe what the new time is--number of hours apparently elapsed vs. number of hours you add()ed and TZ.
Do this for both the current TZ rules and the previous ones, if they changed recently.
To create the Calendar in the proper TZ, if it's not your default TZ, you'll want to use SimpleDateFormat, and then get its millis and make a Calendar from that.
jverda at 2007-7-21 22:22:10 >
Java Essentials New Topic
Java Essentials Hot Topic
Java Essentials
All Classified
- Archived Forums
- Enterprise & Remote Computing
- Java Essentials
- Desktop
- Core
- Solaris Operating System
- Security
- Database Connectivity
- Java Mobility Forums
- Web & Directory Servers
- Development Tools
- Application & Integration Servers
- Java HotSpot Virtual Machine
- Other Topics
- E-Mail, Calendar, & Collaboration
- Developer Tools
- General
- Administration Tools
- Sun Hardware
- Storage Forums
- Java Enterprise System
- StarOffice
- Open Source Technologies
- BigAdmin
- Real-Time
- Java Coding