• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 328
  • Last Modified:

SimpleDateFormat parses differently on 2 machines

I have two machines, one is production and the other is development. They were built identically with:
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");
                  d = _dateFormat.parse(date + " " + time + " " + ampm);

                  GregorianCalendar calendar = new GregorianCalendar(tz);
                  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,
[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,
[DEBUG][SCHEDULER]  startDateToUse: Sunday, December 2, 2007 10:00 PM Pacific Standard Time

  • 4
  • 3
  • 2
1 Solution
Did you check the OS DST settings on each box?
any reason u don't set the timezone on the parse format?
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)
7 new features that'll make your work life better

It’s our mission to create a product that solves the huge challenges you face at work every day. In case you missed it, here are 7 delightful things we've added recently to monday to make it even more awesome.

JerryNortonAuthor Commented:
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
> 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?



The phenomenon your question addresses has nothing to do with formatting
JerryNortonAuthor Commented:

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.
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
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 4
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now