JDK-7130335 : Problem with timezone in a SimpleDateFormat
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 6u24
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2012-01-16
  • Updated: 2014-11-19
  • Resolved: 2012-08-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other JDK 6 JDK 7 JDK 8
5.0-poolFixed 6u31-revFixed 7u4Fixed 8 b25Fixed
Related Reports
Relates :  
SHORT SUMMARY:  Inaccurate date reports when using yyyy/MM/dd HH:mm:ss.S z 
date format on a Timezone with historical TZ rules
INDICATORS:  Can occur when parsing date strings with TimeZone included, the 
"z" element.
SimpleDateFormat class can incorrectly calculate a DST offset when parsing 
date strings that contain the TimeZone. If the parsed TZ has used different 
rules over past years, then the hour offset from the DST calculation may be 
incorrect. In general, applications shouldn't rely on time zone abbreviations 
for parsing of date strings. e.g CST can represent different timezones across 
the globe.

KNOWN WORKAROUND: Don't use timezone abbreviations in timezones strings that 
are to be parsed. Perhaps store the timezone separately.
NOTES FOR SE: Dev engineer has proposed some changes to correct this. It 
should first be ported to JDK 8 and baked/tested there for compatibility 
behaviour. Once satisfied, we can port it to a JDK 6 update release.


EVALUATION SimpleDateFormat calls TimeZone.getRawOffset() which doesn't deal with any historical GMT offset changes. It should avoid the use of the fixed GMT offset.