RDBMS/EBS - DST patches, Turkey decided not to observe daylight saving time anymore

In the last few years, Turkey have changed the daylight saving rules. In 2015, the government has deciced to delay the DST change for two weeks and now this year, Turkey decided not to observe daylight saving time anymore.

Well these kinds of changes have brought us a responsibility to change our system environments, the timezone data and dst rules actually.

I wrote some articles about this DST changes and their affects in the last few years, I will not go into the details about the affects of these changes in this article, but I will do an overview, give you the things that we have done this year to configure our EBS systems according to this  DST rules change and give you some support notes for dealing with these kinds of DST rule changes in different layers of our system environments.

Before going forward, please read the following articles for having the necessary info...

http://ermanarslan.blogspot.com.tr/2014/04/ntp-and-timezone-data-why-do-we-need.html

http://ermanarslan.blogspot.com.tr/2015/10/linux-oracle-about-dst-patches-turkey.html

Well, this year the change in Turkey's DST rules became more obvious, so Oracle and other vendors released lots of articles for the affects of these changes and the things to be done for being aligned with these changes.

The things to be done, however; seems to be different according to our environments, actually according to the datatype and objects that our databases or applications use.

MOS document named "Turkey Continues on Daylight Saving Time From 2016 - Impact on Oracle RDBMS (Doc ID 2185562.1)", has clearly identified the issue and given the instruction for the affected environments.

The MOS document with ID: 2185562.1 was especially written for the Database tier and it has given us a check list to make us ensure if our Database environments are affected by this change.

The main areas that may be affected were;

The DATE dataype and SYSDATE 

Usage of TimeStamp with (Local) Time Zone datatype.

TimeStamp with Time Zone datatype

TimeStamp with Time Zone columns

Database timezone and Session timezone

Usage of JDK in Oracle Home

Usage of JVM in Oracle Database (with timezone and local time) -- EBS does not use this.

Usage of DBMS_SCHEDULER for custom and critical database jobs.

...

That is, altough installing the OS tzdata rpm is mandatory, we could decide if we need to apply the DST patches for the database, OVJM, JDK in Oracle Home and etc. We could decide by checking our database tier by using the info and scripts given in the support node, 2185562.1 .

So, at the end of the day, the decision was ours . "If we were infected, we must apply, if we were not affected(not dependent on the items given in the above list) , then we could decide whether to apply or not.

However, this was only for the database tier. Well... Think about EBS.. In EBS, we have application tier components right? We have FMW, Oracle Homes, Concurrent Tier and etc..

So, we needed to follow a speficic document for EBS, as you may guess.

There were 2 document in this scope and they were different to eachother according to the EBS version that were written for.

Complying with Daylight Saving Time (DST) and Time Zone Rule Changes in E-Business Suite 12(Doc ID 563019.1)

Complying with Daylight Saving Time (DST) and Time Zone Rule Changes in E-Business Suite 11i(Doc ID 458452.1)

These documents were actually contains the instructions in the DST document prepared for the RDBMS (2185562.1)), but they also included instructions specific to the EBS under the section named  Application Server Tier Patches.

The interesting and dissapointing thing was the patches documented in those notes, were not present for EBS application tier components . This was true for EBS 12.2, as well. 

The patches were not available for EBS because the application server components used in EBS, were actually old versions. 

For example, the  FMW home version, for instance was 11.1.0.7. The Oracle Homes were also old.

It didn't  matter if we use EBS 12.2 or 12.1 or 12.0... The patches were not there and we needed  to log Support Requests in order to obtain these patches.

This was quite dissapointing because this was even true for the latest EBS , which was 12.2.

The consequences of not applying these patches, were also given in those documents. So again, it became a decision to apply or not to apply these patches.

Here are the consequences;

• If you enabled User Preferred Time Zone at your site, the Date with Time components displayed in interactive user interfaces might be incorrect.
• The system generated dates and dates with time component might be incorrect. For dates without time components, the incorrect date might be generated. --> This is from OS.
• If you ar using Gantt Charts, time zone related functionality such as scheduling and representations in Gantt charts will be incorrectly rendered.
• Unpatched E-Business Suite environments that have been integrated with external systems will process inbound and outbound data with time components incorrectly.

So, this meant; if we were not using the things in the above list, we were not affected. That is, we could decide to not to apply the patches in EBS apps tier, and actually this was what we have done in most of our customer environments;

So at the end of the day; what we have done was, checking the database tier and the items in above consequences list, seeing that the environments were not affected and then applying the OS patches only.

We have done this in more than 10 customer environments and didn't see an issue. (however, we have done the checks the right? so it may not be your case)

The instructions for dealing with the DST rule changes in Engineered systems were also differ. For example, Oracle released a seperate document for Exadata, Exadata Instructions as Turkey Continues on Daylight Savings Time From 2016 (Doc ID 2195169.1).

Well, in short; in order to deal appropriately with DST rule changs, we need to discover our environments, we need to check our environment component by component by following the documents specifically written for the components and decide whether to take action or not. Ofcourse, the best way is to apply all the action plans for all the environments and components that we have in our Infrastructure, but if we think that we are not affected, the decision and the risk is still ours.