Latest DSTv14 Timezone Patches Available for E-Business Suite

Wooden_hourglass_small2.jpg
If your E-Business Suite Release 11i or 12 environment is configured to support Daylight Saving Time (DST) or international time zones, it's important to keep your timezone definition files up-to-date. They were last changed in January 2010 and released as DSTv13. DSTv14 is now available and certified with Oracle E-Business Suite Release 11i and 12.

Is Your Apps Environment Affected?

When a country or region changes DST rules or their time zone definitions, your Oracle E-Business Suite environment will require patching if:
  • Your Oracle E-Business Suite environment is located in the affected country or region OR
  • Your Oracle E-Business Suite environment is located outside the affected country or region but you conduct business or have customers or suppliers in the affected country or region
We last discussed the DSTv13 patches on this blog. The latest "DSTv14" timezone definition file is cumulative and includes all DST changes released in earlier time zone definition files. DSTv14 includes changes to the following timezones since the DSTv13 release:
  • Africa/Casablanca,
  • Africa/Tunis,
  • America/Argentina/San_Luis,
  • America/Argentina/San_Luis,
  • America/Tijuana, America/Santiago,
  • America/Asuncion,
  • Antarctica/Casey,
  • Antarctica/Davis,
  • Asia/Dacca,
  • Asia/Taipei,
  • Asia/Karachi,
  • Asia/Gaza,
  • Asia/Damascus,
  • Asia/Kamchatka,
  • Asia/Anadyr,
  • Europe/Samara,
  • Pacific/Easter,
  • Pacific/Fiji,
  • Pacific/Apia,
  • America/Ensenada,
  • Chile/Continental,
  • Asia/Dhaka,
  • ROC,
  • Chile/EasterIsland,
  • Mexico/BajaNorte
What Patches Are Required?

In case you haven't been following our previous time zone or Daylight Saving Time (DST)-related articles, international timezone definitions for E-Business Suite environments are captured in a series of patches for the database and application tier servers in your environment. The actual scope and number of patches that need to be applied depend on whether you've applied previous DST or timezone-related patches. Some sysadmins have remarked to me that it generally takes more time to read the various timezone documents than it takes to apply these patches, but your mileage may vary.

We've published the following Notes which identify the various components in your E-Business Suite environment that may need DST patches:
Related Articles

Comments:

Steve,

Would you recommend implementing Virtual Private Database (VPD) features in 11g for certain Project role based security requirement in Oracle Project Management (PJT) application, instead of exploring the project role based security features of the Application and looking at related alternative options that might be available? It is my understanding that VPD, while elegant comes at the cost of substantial configuration and maintenance. Further, its integration and supplementing EBS standard security features need to be understood before proceeding that route.

Your expert opinion and advise is greatly appreciated.

Regards

Ravi

Posted by Ravi Shankar on July 14, 2010 at 02:45 AM PDT #

Ravi,

It's technically feasible to use VPD with the E-Business Suite. Remember that any modifications to support VPD would be considered customizations, with all of the concomitant issues (support complications, maintenance updates whenever we issue new EBS patches, maintenance updates whenever we issue new techstack certifications, complications when upgrading between EBS releases, etc). For a more in-depth discussion about customizations, see:

To Customize or Not to Customize?
http://blogs.oracle.com/stevenChan/2009/11/ebs_customization_implications.html

Only you can determine whether the (substantial) costs and operational hassle of customizations is worth it to you. In general, I would be very skeptical of any claims that the business benefits outweigh the costs, but your mileage will vary.

Regards,
Steven

Posted by Steven Chan on July 14, 2010 at 04:04 AM PDT #

Apparently the 11i patch 9751299 (OJVM) detailed in 458452.1 is AWOL with the exception of RDBMS 11.2. I've opened an SR on the issue but it looks unpromising.

Posted by Kevin Kempf on July 14, 2010 at 11:19 PM PDT #

Hi, Kevin,

Sorry that you're having trouble getting this patch. I've asked one of my engineers to look into this.

BTW, I thought your blog article about installing OEM 11g was excellent. I always find your running commentaries hilarious.

Regards,
Steven

Posted by Steven Chan on July 15, 2010 at 01:52 AM PDT #

Hi, Kevin,

It looks like those patches were regenerated in the last couple of days, so you may have tried to access them while they were temporarily unavailable. They should be available for download now.

Regards,
Steven

Posted by Steven Chan on July 16, 2010 at 01:03 AM PDT #

Steven,

You were right about the the patch; it became available about a week after your posting. Lucky me, I applied the patch series to my 11i test environment, and now have a bug filed against the patchset for linux x86 (bug 9920365 on SR 3-1935719561)

Posted by Kevin Kempf on July 19, 2010 at 12:43 AM PDT #

Hi, Kevin,

Sorry to hear that you're having trouble with this. I've asked one of my engineers to look this over and follow-up with Support if they can assist.

Regards,
Steven

Posted by Steven Chan on July 19, 2010 at 01:11 AM PDT #

Steven,
Per your notes above, it appears that there are DST changes in v14 for the Asia/Taipei area, but Googling this I do not see any changes; Taiwan not not observe DST nor do they plan to do so in the near future. Can you be more specific as to the changes in DST v14 expected for Taipei?
Thank you,
Mark Rogers

Posted by Mark Rogers on August 02, 2010 at 01:40 AM PDT #

Hi Mark,

You are correct Taipei does not observer DST. The changes were implemented in tzdata 2010i and are purely historical, ranging back to alterations in 1979 and the removal of DST in 1980 !

Regards,
Tim.

Posted by Tim Mervyn on August 02, 2010 at 02:14 AM PDT #

Hello. After 30.10.2011 in Moscow we have a big trouble with timezone when we connecting to Oracle 10 throught hibernate. If Record in table have time between 3 and 4 AM.

sun.util.calendar.ZoneInfo.getOffset(ZoneInfo.java:356)
oracle.jdbc.driver.DateTimeCommonAccessor.zoneOffset(DateTimeCommonAccessor.java:433)
oracle.jdbc.driver.DateTimeCommonAccessor.getMillis(DateTimeCommonAccessor.java:471)
oracle.jdbc.driver.TimestampAccessor.getTimestamp(TimestampAccessor.java:134)
oracle.jdbc.driver.OracleResultSetImpl.getTimestamp(OracleResultSetImpl.java:796)
oracle.jdbc.driver.OracleResultSet.getTimestamp(OracleResultSet.java:1661)
org.apache.commons.dbcp.DelegatingResultSet.getTimestamp(DelegatingResultSet.java:300)
org.apache.commons.dbcp.DelegatingResultSet.getTimestamp(DelegatingResultSet.java:300)
org.hibernate.type.TimestampType.get(TimestampType.java:53)
org.hibernate.type.NullableType.nullSafeGet(NullableType.java:184)
org.hibernate.type.NullableType.nullSafeGet(NullableType.java:173)
org.hibernate.type.AbstractType.hydrate(AbstractType.java:105)
org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2267)
org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1423)
org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1351)
org.hibernate.loader.Loader.getRow(Loader.java:1251)
org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:619)
org.hibernate.loader.Loader.doQuery(Loader.java:745)
org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:270)
org.hibernate.loader.Loader.doList(Loader.java:2294)
org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2172)
org.hibernate.loader.Loader.list(Loader.java:2167)
org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:448)
org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:363)
org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196)
org.hibernate.impl.SessionImpl.list(SessionImpl.java:1258)
org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)

We think that it depends on changing in our legislation which abolish Daylight Saving Time changes in Russia.

What should we do to solve this error?

Posted by Alexey on October 31, 2011 at 08:21 PM PDT #

Hello, Alexey,

You may have missed this announcement, which covers the DSTv17 update that includes the latest Russian timezone definitions:

Latest DSTv17 Timezone Patches Available for E-Business Suite R11i
http://blogs.oracle.com/stevenChan/entry/latest_dstv17_timezone_patches_available1

Regards,
Steven

Posted by Steven Chan on November 01, 2011 at 03:32 AM PDT #

We use Oracle 10g does is it possible to apply the patch on Oracle 10g?
And one more.
We take odbc6 from SQLDeveloper and now there are no exception but rows in SQL Developer and our program have different DateTime if this row`s time between 3 and 4 AM/

Posted by Alexey on November 01, 2011 at 05:21 PM PDT #

Alexey,

Yes, this patch should be applicable on the 10g database; please review the patch's instructions for details.

I'm afraid that I can't help with your SQL Developer questions; that's not an E-Business Suite product. Your best bet would be to log a formal Service Request via My Oracle Support (formerly Metalink) to get one of our SQL Developer specialists engaged.

Regards,
Steven

Posted by Steven Chan on November 02, 2011 at 04:05 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today