LO58322: IF DST IS SET TO TAKE PLACE AT MIDNIGHT, DOMINO DOES NOT ACTUALL Y CHANGE TIME UNTIL 2AM

Subscribe to this APAR

By subscribing, you receive periodic emails alerting you to the status of the APAR, along with a link to the fix after it becomes available. You can track this item individually or track all items by product.

Notify me when this APAR changes.

Notify me when an APAR for this component changes.

APAR status

  • Closed as program error.

Error description

  • If the DST change will be happening at midnight as opposed to
    2AM, even though
    the change happens at midnight, Domino does not change its time
    until 2AM,
    leaving a window of time where the Domino server time is
    incorrect.  A way of
    reproducing this is to set up an OS to be in Egypt or Brazil
    Time zone with the
    Date set to just before DST is to take place.  You can see the
    OS time change
    at midnight, but Dominos time doesnt change until 2AM.
    

Local fix

Problem summary

  • Day 1 behavior was to always change DST at 2AM for Start, and
     1AM for end.  This was a hinderance, but still ok until
     Windows started to change DST on prior day at 11:59PM.  This
     fix is for all platforms where customers can set when to
     change DST, but for windows specifically we can sync with OS
     and read that information from same structure we already use
     for formula behind DST Boundary Day.    This has been an issue
     on Servers affecting products like Traveler, and Client
     affecting Calendar & Scheduling.  Fix is conditional, and not
     turned on unless DSTLAWTIME is used in Notes.ini  If the
     values are invalid it will revert to default.    I have
     already fixed a few Calendar & Scheduling issues as a
     repurcussion, and expect others.  Midnight boundary was never
     tested, and leading to some issues that I will adress as I get
     the SPR's behind them.  Can really only address core C&S, Web
     access C&S is mostly in JavaScript and didn't get much help in
     locating logic, and for Standard Client, this is in an area
     not accessible to me and in Java.    These directories need to
     be rebuilt for Server side fix (DLLTEST too)  misc, os,
     compute, net, nif, nsf, schgtw, lsxbe, mailmisc, mime, server,
     insrv\inotes, schedule    Client HF  needs the above for
     DLLTEST + these below  view, schui, Desk, wmisc, Edit
    

Problem conclusion

  • Day 1 behavior was to always change DST at 2AM for Start, and
     1AM for end.  This was a hinderance, but still ok until
     Windows started to change DST on prior day at 11:59PM.  This
     fix is for all platforms where customers can set when to
     change DST, but for windows specifically we can sync with OS
     and read that information from same structure we already use
     for formula behind DST Boundary Day.    This has been an issue
     on Servers affecting products like Traveler, and Client
     affecting Calendar & Scheduling.  Fix is conditional, and not
     turned on unless DSTLAWTIME is used in Notes.ini  If the
     values are invalid it will revert to default.    I have
     already fixed a few Calendar & Scheduling issues as a
     repurcussion, and expect others.  Midnight boundary was never
     tested, and leading to some issues that I will adress as I get
     the SPR's behind them.  Can really only address core C&S, Web
     access C&S is mostly in JavaScript and didn't get much help in
     locating logic, and for Standard Client, this is in an area
     not accessible to me and in Java.    These directories need to
     be rebuilt for Server side fix (DLLTEST too)  misc, os,
     compute, net, nif, nsf, schgtw, lsxbe, mailmisc, mime, server,
     insrv\inotes, schedule    Client HF  needs the above for
     DLLTEST + these below  view, schui, Desk, wmisc, Edit
    

Temporary fix

Comments

  • This APAR is associated with SPR# JRED8DVKSU.
    Day 1 behavior was to always change DST at 2AM for Start, and
     1AM for end.  This was a hinderance, but still ok until
     Windows started to change DST on prior day at 11:59PM.  This
     fix is for all platforms where customers can set when to
     change DST, but for windows specifically we can sync with OS
     and read that information from same structure we already use
     for formula behind DST Boundary Day.    This has been an issue
     on Servers affecting products like Traveler, and Client
     affecting Calendar & Scheduling.  Fix is conditional, and not
     turned on unless DSTLAWTIME is used in Notes.ini  If the
     values are invalid it will revert to default.    I have
     already fixed a few Calendar & Scheduling issues as a
     repurcussion, and expect others.  Midnight boundary was never
     tested, and leading to some issues that I will adress as I get
     the SPR's behind them.  Can really only address core C&S, Web
     access C&S is mostly in JavaScript and didn't get much help in
     locating logic, and for Standard Client, this is in an area
     not accessible to me and in Java.    These directories need to
     be rebuilt for Server side fix (DLLTEST too)  misc, os,
     compute, net, nif, nsf, schgtw, lsxbe, mailmisc, mime, server,
     insrv\inotes, schedule    Client HF  needs the above for
     DLLTEST + these below  view, schui, Desk, wmisc, Edit
    

APAR Information

  • APAR number

    LO58322

  • Reported component name

    DOMINO SERVER

  • Reported component ID

    5724E6200

  • Reported release

    850

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt

  • Submitted date

    2011-02-08

  • Closed date

    2015-01-28

  • Last modified date

    2015-01-28

  • 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

    DOMINO SERVER

  • Fixed component ID

    5724E6200

Applicable component levels

  • R850 PSN

       UP



Document information


More support for:

IBM Domino

Software version:

8.5

Reference #:

LO58322

Modified date:

2015-01-28

Translate my page

Content navigation