As Daylight Saving Time is fast approaching, we wanted to make everyone aware of SAP BI Platform’s readiness.

Daylight Saving Time starts in the United States on March 13 at 2am.  DST starts in most of Europe on March 27 at 1am.

SAP Development regularly tests all products and patches for Daylight Saving Time, but we in Support make a point of performing additional testing in all of the latest Support Packages as well.  This year, I extensively tested DST scenarios within the following:

  • SAP BusinessObjects Enterprise XI 3.1, Service Pack 7
  • SAP Business Intelligence Platform 4.1, Support Package 7
  • SAP Business Intelligence Platform 4.2, Support Package 01 (stay tuned for BI 4.2!)

Happily, there are no new issues to report!  The Daylight Saving Time switchover in 2016 should be no different than in any recent years.

Although these will not impact most customers, here are a few DST-related Knowledge Base Articles that are worth mentioning:

KBA 1404484 – Unix and Linux envioronments should have the $TZ variable correctly set to account for the date and time of the DST time changes in your region; both Spring and Autumn.  Non-US customers should especially be aware of this, because if the $TZ variable is not set then your system may default to honoring US DST rules.  If instance runtimes suddenly appear to be one hour earlier or later starting the day the US changes their clocks for DST, this is your issue!

KBA 1986781 – If an instance’s runtime falls within the one-hour period skipped over by Daylight Saving Time, its runtime will automatically be adjusted by + one hour.  Recurring instances’ runtimes are permanently adjusted, and should be re-scheduled if need be.  e.g. in the US, Spring DST immediately shifts the clock from 2am>3am.  If an instance runs on Sundays at 2:30am, starting the week of DST it will now run at 3:30am.  Only instances with a scheduled start time falling within this one-hour period are affected!

KBA 1448881 – This is a carryover from 5 years ago now.  Enterprise XI 3.1 had an issue where a recurring instance might suddenly spawn hundreds of failed instances per second, leading to thousands+ instances clusttering that object’s history.  The solution was to re-schedule the affected instance, and a program object could be used to clean up the unwanted failed instances.  I only list this one because, whie the issue was fixed in XI 3.1 Fix Packs 3.6 / 4.1 and Service Pack 5, there have been very few reports of similar behavior in BI 4.x.  In the extremely rare case of this issue occurring in BI 4.x, it seems to be a less severe issue.  In any version, the solution — described within this KBA — remains the same.

If you encounter any other issues around Daylight Saving Time, please do let us know!

Thanks and regards

-Mike

To report this post you need to login first.

9 Comments

You must be Logged on to comment or reply to a post.

  1. Jon Fortner

    I’d guess most are not up to 4.1 SP7 yet. Do you know of issues in SP5 Patch 5? I would suggest coverage of any SPs back to March of 2015.

    (0) 
    1. Michael Richards Post author

      Hi Jon,

      Thank you — yes, I should’ve been clearer on that point.  We do this testing annually, on whatever the latest SPs happen to be.  Last year, the same testing was done on BI 4.1 SP05.  So, while I haven’t tested every Patch in between, SAP Development has / and there are no DST issues reported between last year’s testing in BI 4.1 SP05 and this year’s testing in BI 4.1 SP07.  So, it stands to reason that the chances of an issue BI 4.1 Patch 5.5 are extremely slim.

      I hope that helps!

      Thanks again

      -Mike

      (0) 
  2. Walter Tran

    Just wanted to add that I had a client on BI 4.1 SP7 P1, and experienced the issue with schedules being out of the time interval and all newly scheduled reports being stuck in pending status.

    Ended up having to restart the AJS and re-schedule all reports using the EDST tool found in KBA 1448881.

    And to provide some background, the BIP server was initially installed with BI 4.1 SP5 and content was created in the BI 4.1 environment, nothing from XI 3.1 or BI 4.0.

    (0) 
  3. Henrik Behrndt

    On BI 4.1, SP4, we last year very much saw the problem described in “1448881 – Multiple instances spawned after daylight savings time change”. We manually had to remove 1000’s of failed schedule entries. This was cumbersome, as the “Limits” setting does not work as intended either. This year, we will simply stop the job servers and tell users, no scheduled jobs will be running during the Easter weekend. The installation was originally done as BO 4.0 SP4.


    (0) 
  4. Nick Cameron

    We still have the 1448881 problem appearing on BI 4.1 SP05 patch 3 and we’re not planning on patching up until 2017. All appear to be Daily schedules but get thousands of instances failing. Not all daily schedules are doing this and we have ones that run at the same time and the schedule created at the same time with virtually the same details with no issues.  We had some last year too. It’s not an option for us to stop all of the Job Servers so we have to just try and reschedule them again once they fail. It would be nice if there was some more detailed information about what specifically about the scheduled instance maybe causing this so that we could try and see in advance which ones may have the problem.

    (0) 
  5. Darren Skuse

    Issue I am having is when a user is scheduling a report and the webi prompt has a date to be selected. The calendar pop up will open and I select 12/04/2016 00:00:00 and then press done. The saved date in the summary now add an hour 12/04/2016 01:00:00.

    I have set the locale in infoview to GMT but still happens.

    BO 4.1 SP6 p2

    (0) 
  6. Michael Tibbit

    Hi, I am in the UK and our schedules “changed” by an hour when UK DST kicked in – in comparison to UTC they stayed the same, then they changed back a week later when US DST kicked in.
    This sounds very much like KBA 1404484 I am unclear on the resolution though. We have the TZ environment variable set but not in POSIX format. Is it essential to use this format? I have asked our Unix guys to make the change but they have questioned it as they haven’t seen it needed in this format for 10+ years. We are on 4.1 SP6.
    Thanks
    Mike 

    (0) 

Leave a Reply