IV18033: DIFFERENCE OF 4 SECONDS IN DATE->STRING->DATE CONVERSION USING SIMPLEDATEFORMAT CLASS WITH ASIA/RIYADH89(/88/87) TIMEZONES

Subscribe

You can track all active APARs for this component.

APAR status

  • Closed as Permanent restriction.

Error description

  • 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
    .
    

Local fix

  • 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).
    

Problem summary

  • 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.
    

Problem conclusion

  • 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.
    

Temporary fix

Comments

APAR Information

  • APAR number

    IV18033

  • Reported component name

    JAVA CLASS LIBS

  • Reported component ID

    620700130

  • Reported release

    600

  • Status

    CLOSED PRS

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2012-03-21

  • Closed date

    2012-04-07

  • Last modified date

    2012-04-07

  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels



Rate this page:

(0 users)Average rating

Add comments

Document information


More support for:

Runtimes for Java Technology
Java Class Libraries

Software version:

6.0

Reference #:

IV18033

Modified date:

2012-04-07

Translate my page

Machine Translation

Content navigation