Closed as Permanent restriction.
Error Message: When a date object is formatted using SimpleDateFormat with TimeZone set to Riyadh89/88/87 and parse back to the Date object, there is a 4 seconds difference when the format string contains TimeZone pattern(i.e., Z or zzzz). . Stack Trace: N/A .
1. Use Asia/Riyadh TimeZone which is currently active. . 2. If the Asia/Riyadh87(88/89) needs to be used, avoid using format strings containing TimeZone specifiers in format string of DateFormat object with Asia/Riyadh87(88/89) (using Z or zzzz in the format String).
The problem was caused as Riyadh 87-89 time zones do not follow the common time zone standards - RFC822 time zone or Generalized Time zone standards where as JDK follows common time zone standards. While using SimpleDateFormat class to convert a date to a string, only the seconds precision in the Time zone offset is considered. This is well documented in the SimpleDateFormat class API as it follows RFC822 timezone or Generalized Time zone standards. All the standard locales are standardized their time zone offset to 15, 30, 45 or 00 minutes. Hence "Asia/Riyadh" time zone is standardized to 03:00. IBM JDK retains Riyadh87-89 time zones for compatibility purpose as any application which continues to use Riyadh87-89 time zones can break if they are removed.
When you convert a Date to string using SimpleDateFormat format with Riyadh87-89 time zone, the JDK will use Riyadh87-89 time zone offset for the conversion. Here, you are losing 4 seconds offset as seconds precision offset are not preserved in the string format. When the string is parsed back to Date, it uses the time zone offset from the string and hence, every time you do a Date -> String -> Date conversion, you will gain 4 seconds which explains why you are seeing the 4 seconds difference every time. In order to fix this issue, either the seconds value in Riyadh87-89 time zone offset has to be ignored while doing the formatting from Date to String or JDK has to add the seconds precision to string format. If the seconds value from Riyadh87-89 time zone offset is ignored, JDK will provide incorrect timestamp in the string format. In order to add the seconds precision to string format, JDK has to deviate from the common standards (RFC822 timezone and Generalized Time zone). Hence JDK decided not to fix this issue and considered this as a perminent restriction.
Reported component name
JAVA CLASS LIBS
Reported component ID
Last modified date
APAR is sysrouted FROM one or more of the following:
APAR is sysrouted TO one or more of the following: