Solved

SimpleDateFormat parses differently on 2 machines

Posted on 2007-11-17
9
307 Views
Last Modified: 2012-05-05
I have two machines, one is production and the other is development. They were built identically with:
J2SDK_1.4.2_14
RedHat E 4.0
Tomcat 5.0.28
Both display the time as:
Sat Nov 17 22:33:11 UTC 2007
As root, I do not see any TZ set on either.

I have a jsp page that sends in a string (date) such as '12/2/2007' for december 2, 2007. It adds string (time) in a 12 hour string format (10:00) and either AM or PM. It also has the timezone such as 'America/Los_Angeles'
On both machines, the same code runs:

                   Date d = null;
                   //timezone corrections
                   TimeZone tz = TimeZone.getTimeZone(timezonename);

                  if(DEBUG)System.out.println("[DEBUG][SCHEDULER] Date and  TZ : " + date + " " + time + " " + ampm + " "+ tz.getDisplayName(true,TimeZone.LONG));
                  SimpleDateFormat _dateFormat = new SimpleDateFormat("MM/dd/yyyy h:mm a");
                  SimpleDateFormat _writeFormat = new SimpleDateFormat("EEEEE, MMMMM d, yyyy h:mm a zzzz");
                  _writeFormat.setTimeZone(tz);
                  d = _dateFormat.parse(date + " " + time + " " + ampm);

                  GregorianCalendar calendar = new GregorianCalendar(tz);
                  calendar.setTime(d);
                  if(DEBUG)System.out.println("[DEBUG][SCHEDULER]  Date from calendar " + calendar.toString() );
                  calendar.add(Calendar.MINUTE, -1*((calendar.get(Calendar.ZONE_OFFSET) + calendar.get(Calendar.DST_OFFSET)) / (60 * 1000)));
                  if(DEBUG)System.out.println("[DEBUG][SCHEDULER]  timezone correction in minutes: " +(calendar.get(Calendar.ZONE_OFFSET) + calendar.get(Calendar.DST_OFFSET)) / (60 * 1000) );
                  startDateToUse = _writeFormat.format(calendar.getTime());
                  if(DEBUG)System.out.println("[DEBUG][SCHEDULER]  startDateToUse: " +startDateToUse );

PROBLEM: on one machine, i get the expected results. On the other I get the wrong results. It seems to be the parser not working right.

The debug from the 'bad' machine: (note the AM_PM setting and the HOUR OF DAY)
[DEBUG][SCHEDULER] Date and  TZ : 12/2/2007 10:00 PM Pacific Daylight Time
[DEBUG][SCHEDULER]  Date from calendar java.util.GregorianCalendar[time=1196618400000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,
zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,
useDaylight=true,transitions=185,lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,
startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,
endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2007,MONTH=11,WEEK_OF_YEAR=49,WEEK_OF_MONTH=2,DAY_OF_MONTH=2,DAY_OF_YEAR=336,
DAY_OF_WEEK=1,DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=10,HOUR_OF_DAY=10,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=-28800000,DST_OFFSET=0]
[DEBUG][SCHEDULER]  timezone correction in minutes: -480
[DEBUG][SCHEDULER]  startDateToUse: Sunday, December 2, 2007 6:00 PM Pacific Standard Time

Same input on Good machine:

[DEBUG][SCHEDULER] Date and  TZ : 12/2/2007 10:00 PM Pacific Daylight Time
[DEBUG][SCHEDULER]  Date from calendar java.util.GregorianCalendar[time=1196632800000,areFieldsSet=true,areAllFieldsSet=true,lenient=true,
zone=sun.util.calendar.ZoneInfo[id="America/Los_Angeles",offset=-28800000,dstSavings=3600000,useDaylight=true,transitions=185,
lastRule=java.util.SimpleTimeZone[id=America/Los_Angeles,offset=-28800000,dstSavings=3600000,useDaylight=true,startYear=0,
startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,
endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,
YEAR=2007,MONTH=11,WEEK_OF_YEAR=49,WEEK_OF_MONTH=2,DAY_OF_MONTH=2,DAY_OF_YEAR=336,DAY_OF_WEEK=1,
DAY_OF_WEEK_IN_MONTH=1,AM_PM=1,HOUR=2,HOUR_OF_DAY=14,MINUTE=0,SECOND=0,MILLISECOND=0,ZONE_OFFSET=-28800000,DST_OFFSET=0]
[DEBUG][SCHEDULER]  startDateToUse: Sunday, December 2, 2007 10:00 PM Pacific Standard Time

0
Comment
Question by:JerryNorton
  • 4
  • 3
  • 2
9 Comments
 
LVL 86

Expert Comment

by:CEHJ
ID: 20305781
Did you check the OS DST settings on each box?
0
 
LVL 92

Expert Comment

by:objects
ID: 20305784
any reason u don't set the timezone on the parse format?
0
 
LVL 92

Accepted Solution

by:
objects earned 500 total points
ID: 20305800
you need to either set the timezone for the parse format
or include tthe timezone in the time to be parsed (and add it to the format string)
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 20305841
0
Threat Intelligence Starter Resources

Integrating threat intelligence can be challenging, and not all companies are ready. These resources can help you build awareness and prepare for defense.

 

Author Comment

by:JerryNorton
ID: 20306479
Hi, thanks for the quick answers, but .....
1) TZupdater is included in 1.4.2_14 ( we switched from _05 for that reason).
2) Still need to know what could be different between the two machines
0
 
LVL 92

Expert Comment

by:objects
ID: 20306727
> 1) TZupdater is included in 1.4.2_14 ( we switched from _05 for that reason).

your timezones are fine :) you don't need to run that

> 2) Still need to know what could be different between the two machines

Have you checked what they are?

TimeZone.getDefault()

or

dateFormat.getTimezone();
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 20307937
The phenomenon your question addresses has nothing to do with formatting
0
 

Author Comment

by:JerryNorton
ID: 20349884
CEHJ:

You are right. As is true with at least 50% of the problems I see in EE, the solutions address a different issue than the problem. BUT it did clear up the trouble. The root problem, as near as I could reproduce, was that there WAS a different timezone set on on machine (production) when it was installed. This was cleared in linux by removing the /etc/localtime file. Java must stick some info (as to default timezone) in a config file somewhere (& not use the current settings).

Since we used objects idea of setting the tz explicitly instead of assuming a new calendar would be in GMT, it all works fine now.
0
 
LVL 86

Expert Comment

by:CEHJ
ID: 20350182
If the timezone is set correctly on the machine, there should be no reason to set it in Java (unless you want a different TZ from the local one)

>>This was cleared in linux by removing the /etc/localtime file

You almost certainly don't want to do that - it could mess up the settings for the system and other software
0

Featured Post

How to improve team productivity

Quip adds documents, spreadsheets, and tasklists to your Slack experience
- Elevate ideas to Quip docs
- Share Quip docs in Slack
- Get notified of changes to your docs
- Available on iOS/Android/Desktop/Web
- Online/Offline

Join & Write a Comment

Suggested Solutions

Java had always been an easily readable and understandable language.  Some relatively recent changes in the language seem to be changing this pretty fast, and anyone that had not seen any Java code for the last 5 years will possibly have issues unde…
In this post we will learn how to connect and configure Android Device (Smartphone etc.) with Android Studio. After that we will run a simple Hello World Program.
Viewers will learn about basic arrays, how to declare them, and how to use them. Introduction and definition: Declare an array and cover the syntax of declaring them: Initialize every index in the created array: Example/Features of a basic arr…
This theoretical tutorial explains exceptions, reasons for exceptions, different categories of exception and exception hierarchy.

760 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

20 Experts available now in Live!

Get 1:1 Help Now