IBM Support

JR49056: ISSUE WITH BLACKOUT PERIODS IF SWITCHING FROM DST TO STANDARD TIME

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • Description:
    If a blackout period is defined while daylight savings time is
    active and the begin and end time of the blackout period is to
    be scheduled while standard time is active, then the begin and
    end time will be scheduled one hour early. As an example, if
    the interval is defined in the "Europe/Amsterdam" timezone at
    10/25/2013 (daylight saving time is active) and the interval is
    specified to range from 10/28/2013 18:00 to 10/28/2013 20:00
    (standard time is active),then the interval will be active
    from 10/28/2013 17:00 to 10/28/2013 19:00 - one hour too early.
    

Local fix

  • n/a
    

Problem summary

  • If a blackout period is defined while daylight savings time is
    active and the begin and end time of the blackout period is to
    be scheduled while standard time is active, then the begin and
    end time will be scheduled one hour too early. As an example,
    if the interval is defined in the "Europe/Amsterdam" timezone
    at 10/25/2013 (daylight saving time is active) and the interval
    is specified to range from 10/28/2013 18:00 to 10/28/2013 20:00
    (standard time is active),then the interval will be active from
    10/28/2013 17:00 to 10/28/2013 19:00 - one hour too early.
    
    PROBLEM DETAILED DESCRIPTION:
    The problem occurs because
    - the server uses the client's timezone when scheduling blackout
     intervals
    - the client does not send its 'real' timezone to the server. It
     only sends the offset relative to GMT.
    
    For timezones that make use of DST, this means that the client
    during summer sends a different offset than during winter. In
    this way the server is not aware that the client's timezone
    uses DST and cannot schedule the interval correctly.
    

Problem conclusion

  • This fix introduces code on the ProcessAdmin console client that
    determines the correct timezone and sends the Olson name of the
    timezone via a new cookie to the server.  This happens only if
    the client's timezone makes use of DST. Otherwise, the old
    approach is still used, where the client sends the timezone's
    offset againts GMT to the server.
    
    FIX AVAILABILITY:
    iFix for 8.0.1.1 is/will be available on Fix Central; search for
    APAR JR49056 at http://www.ibm.com/support/fixcentral/
    iFix for 8.0.1.2 is/will be available on Fix Central; search for
    APAR JR49056 at http://www.ibm.com/support/fixcentral/
    iFix for 8.5.0.1 is/will be available on Fix Central; search for
    APAR JR49056 at http://www.ibm.com/support/fixcentral/
    Fix is also targetted for inclusion in next fixpack for
    BPM 8.0.1
    
    When obtaining any of the above fixes, be sure to download the
    accompanying readme, for itself, and any prerequisite fixes, and
    review them thoroughly.
    

Temporary fix

Comments

APAR Information

  • APAR number

    JR49056

  • Reported component name

    BPM STANDARD

  • Reported component ID

    5725C9500

  • Reported release

    801

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2014-01-15

  • Closed date

    2014-03-19

  • Last modified date

    2014-03-19

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

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

Fix information

  • Fixed component name

    BPM STANDARD

  • Fixed component ID

    5725C9500

Applicable component levels

  • R801 PSY

       UP

  • R850 PSY

       UP

[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSFTDH","label":"IBM Business Process Manager Standard"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0.1","Edition":"","Line of Business":{"code":"LOB36","label":"IBM Automation"}}]

Document Information

Modified date:
19 March 2014