Release 12.2 of Oracle E-Business Suite includes as standard a feature called User-Preferred Time Zone Support. In most existing E-Business Suite implementations, all users interact with the system in the corporate time zone, which will normally be the time zone of the headquarters of the implementing company, and the time zone in which the database runs. This means that remote users have to be aware of the time difference between their location and that of the corporate headquarters.
Employing the user-preferred time zone feature enables users to specify their local time zone for both display and entry of date-with-time fields. Key consequences of this are:
Users see date-with-time fields in their preferred (local) time zone, and can enter dates with time in this time zone.
Date fields without a time component are not affected by this feature.
The data in the database continues to be stored in the standard corporate time zone.
This chapter discusses the capabilities, limitations, and implementation details of the user-preferred time zone feature.
Definitions
Server Time Zone/Corporate Time Zone - Server time zone or corporate time zone are used to describe the same concept throughout this chapter. They reflect the primary time zone set at your site, and usually correspond to the time zone of your headquarters or primary operation (the primary legal entity time zone). You set this value in the 'Server Timezone' site level profile. It must match the database level setting for server time zone.
Important: Oracle strongly recommends that the database time zone should not be changed once it has been set and data has been entered.
Client Time Zone/User Time Zone - Client time zone or user time zone are used as synonyms to describe the same concept throughout this chapter. They reflect the time zone in which the user is operating, which is normally also the time zone in which the user is physically located.
Location-Based Time Zone - Location-based time zone refers to the time zone of the contextual location. Uptake of location-based time zone is product-specific, and is not covered in this chapter.
Conceptually, there are two types of date fields:
Dates with a time component – used to indicate a specific point in time within a particular day
Dates without a time component – used to denote a particular day, but not a specific point in time within that day
Date fields with a time component can be represented in any time zone, and thus displayed in whichever time zone is most meaningful to the end user. Generally, users prefer to view dates in their own (local) time zone. With the user-preferred time zone feature enabled, date with time fields will be converted to the user's preferred time zone for display.
Date fields without a time component cannot be represented in different time zones, because no meaningful conversion is possible for a date that does not include a specific time. Such a date is entered with respect to one time zone, and in general must be viewed as a day in that time zone, regardless of the location (and possibly different time zone) in which it is being viewed. Oracle E-Business Suite typically uses the corporate time zone for these day definitions: dates without a time component represent the day with respect to the corporate headquarters (corporate days).
There are some exceptions to this rule. For example, dates without a time component may be held as ANSI dates, to represent dates independently of the time zone in which they are being viewed. In such a case, a benefit that starts on 1st January will start on that date wherever in the world it is made available; that is, it will apply to anyone who is in a time zone where it is 1st January.
Many dates without a time component represent pointers to a financial period. These dates are not meant to indicate the exact hour and minute that a transaction occurred, but rather the financial period into which the transaction is accounted. This is a financial bucketing from the perspective of the implementing company. For example, the invoice dates on Payables or Receivables invoices never change based on who is looking at them: they are classified as invoices for that day (and thus that period), regardless of the viewer. These financial accounting dates are often defaulted or derived from actual transaction dates, and it should be understood that although the transaction dates will be converted to the user's preferred time zone for display, the financial accounting dates will not.
For information about the related topic of compliance with daylight saving time and other time zone adjustments, refer to My Oracle Support Knowledge Document 563019.1, Complying with Daylight Saving Time (DST) and Time Zone Rule Changes in E-Business Suite 12.
For a discussion of time zones in the context of other globalization-related topics, see Globalization Support in Oracle E-Business Suite Concepts.
This section examines the considerations that apply when employing user-preferred time zones with a range of Oracle E-Business Suite components and products.
First, the effect of user-preferred time zones on interactive and non-interactive user interface components will be examined. This is followed by a comprehensive survey of points that should be considered when employing user-preferred time zones with various Oracle E-Business Suite products.
Oracle E-Business Suite derives the user-preferred time zone based on the user profile 'Client Timezone'. This profile option can be set for every user according to individual requirements. Users can also set their preferred timezone from the Preferences page by choosing the appropriate value of the 'Timezone' preference.
When automatic user-preferred time zone conversion is enabled, Forms-based and HTML-based user interfaces will behave as described in the following subsections.
The behavior of Oracle Forms components is described below.
The calendar list of values shows the name of the time zone associated with that date field (this will be the user's preferred time zone if it has been set up, or the corporate time zone if the user has not yet set his time zone preference).
A Convert Time Zone button enables you to view the date with the time value converted to any time zone of interest. This built-in time zone calculator may be useful for users who occasionally need to see a particular date with time in a time zone other than their own. Additionally, you can enter a date with time in a specific time zone of your choosing, and when you close the calendar list of values, the value will be converted to the time zone associated with the field for display.
When you enter search criteria in a date field of a find window, you must be aware of whether you are searching on a date that has a time component or not. Dates without time components will be searched using the standard corporate time zone. Dates with time components will be searched using the user's preferred time zone.
When querying on a date with time field, you can enter a date with a specific time, and retrieve transactions for that specific date and time in your preferred time zone. If you enter only a partial value, however, the query will run as though there is no time component, and return records that match the partial value in the corporate time zone.
Queries on date fields without a time will continue to return records matching the date in the corporate time zone, as in previous releases.
The concurrent request windows or Standard Report Submission form will operate in the user-preferred time zone. The job queues will show the requested dates and times according to the user's local time zone, including jobs that were submitted by users in other time zones. For example, say a job is scheduled to run at 12:30 pm in New York time (GMT-5); if a user in Los Angeles (GMT-8) looks at the queue, then that user will see that the job as scheduled for 9:30 am Los Angeles time (GMT-8).
Concurrent reports output (reports, log files and out files), will, however, always use the standard corporate reporting time zone.
The Forms Record History values (WHO columns) are dates with time but will always be displayed in the corporate time zone.
The behavior of Oracle HTML-based UI components is described below.
The date picker will allow you to pick a specific date, but not a time component. Once a date with time is selected, the time component will generally default to the current time unless otherwise specified. The date with time is displayed in relation to the client time zone.
Unless specified otherwise, date with time based searches are based on the client time zone, and always require a time component to be specified. When left blank, a default time (usually 00:00:00) will be appended.
Unless specified otherwise, date-only based searches will be based on the corporate time zone.
Key and Descriptive Flexfields where the Value Set is defined with the DateTime datatype will have the user-preferred time zone conversion applied. You should review the custom Flexfield Value Set definitions before enabling time zone support. If the user-preferred time zone conversion is considered inappropriate for a particular Flexfield segment. then consider changing the ValueSet used, or the ValueSet datatype.
Note: Oracle-provided DateTime ValueSets and Flexfield segments cannot be changed.
Concurrent Program Parameter definitions are based on Flexfields. On the Process/Report Submission form, all DateTime parameters will honor the user-preferred time zone.
For date values that include a time component, integrator developers can specify at design time whether the value should be displayed in Oracle Web Applications Desktop Integrator spreadsheets according to the server time zone or the client time zone. To do so, developers define interface attributes with a data type of DateTime to display the value in the server time zone or with a data type of DateTimeTZ to display the value in the client time zone.
When a user creates a spreadsheet, date values with a data type of DateTimeTZ are converted to the client time zone specified in the Client Timezone (CLIENT_TIMEZONE_ID) profile option for that user. When the user uploads data from the spreadsheet to Oracle E-Business Suite, date values with a data type of DateTimeTZ are converted back to the server time zone.
In spreadsheets exported from Oracle Application Framework tables, date values that include a time component are displayed according to the client time zone.
When automatic user-preferred time zone conversion is enabled, non-interactive user interfaces will behave as described in the following subsections.
All dates or dates with times loaded into an Oracle E-Business Suite interface table should be converted to the standard corporate time zone prior to loading.
All dates and date with times passed into or out of Oracle E-Business Suite public PL/SQL or Java APIs are assumed to be in the standard corporate time zone, unless specified otherwise. HCM (HRMS) APIs are a notable exception, and HCM (HRMS) dates are in the local time zone of the transaction.
All dates and date with times viewed from the Oracle E-Business Suite schema through any ad hoc reporting tools should be assumed to be in the standard corporate reporting time zone. The exception is HCM (HRMS) dates, which are in the local time zone of the transaction.
Unless specified otherwise, Oracle Reports and Oracle XML Publisher reports display Date and Date with time in corporate time zone.
Whenever data is moved between Oracle E-Business Suite implementations (or from another system into an Oracle system), the time zone of the source system should be compared to the time zone of the Oracle E-Business Suite schema (the standard corporate time zone). If the time zones are different, then the appropriate conversions should be made to all date with time fields before import into Oracle E-Business Suite.
Oracle e-Commerce Gateway is aware of the standard corporate time zone for Oracle E-Business Suite. For selected transactions, the time zone identifier will be bundled with the transaction data itself, so that the destination system can properly interpret the date. Likewise, for inbound transactions, if a time zone is specified with a date field, Oracle e-Commerce Gateway will convert the date to the standard corporate time zone before inserting the data into Oracle E-Business Suite. See the Oracle e-Commerce Gateway documentation for specific transaction details.
Beginning in Release 12.2.7, Oracle Workflow email notifications always display date and time values in the notification recipient's client time zone. If the 'Enable Timezone Conversions' profile option is set to 'Yes', then the emails display a time zone indicator that specifies what the client time zone is. If the profile option is set to 'No', then the time zone indicator is not displayed.
The Service products use a combination of transaction-specific time zones and user-preferred time zones for displaying dates and times. With the user-preferred time zone feature enabled, service agents are able to see dates in their preferred time zone. In addition, they can see the current time in the time zone for the primary contact of the service request. This information can also be used to relate to customers in remote time zones.
Field service technicians are also able to select their preferred time zone and interact with the system in that time zone when requesting material for a repair at a customer site, or requesting availability of material to be picked up or shipped to the work site.
As part of Service setup, consider the following implementation tasks:
Define coverage templates
Define customers
Define calendar, shift, and shift assignments
Define resources and assign resources to calendars
Each of these wiill be described further below.
Coverage templates allow coverage times to be specified in multiple time zones. Use the time zones of your call center locations as the time zones for your coverage templates.
For example, coverage can be offered from 09:00 to 17:00 Eastern Time and 08:00 to 16:00 Central European time for each time zone. Different service levels can then be specified in terms of reaction and resolution times. This allows modeling of multiple call centers, each working in a different time zone.
A particular time zone coverage can also be defined as the default time zone coverage, and applied to all other time zones. This allows modeling of a single call center that works in a specific time zone, and which takes calls at hours specified in that time zone. If you offer 24x7 coverage, you can define a single coverage using any time zone.
The time zone of the location should always be specified when defining addresses for customers and contacts.
Use the Define Shift form to define calendars, shifts, and shift assignments. Shifts are independent of time zones, and can be reused across time zones. For example, if technicians in New York work from 09:00 to 17:00 Eastern Time, and technicians in San Francisco work from 09:00 to 17:00 Pacific Time, only one calendar and one set of shifts should be defined.
When defining a field service technician resource, his primary time zone must be specified in the Service tab, and the resource assigned to the corresponding shift: the shift pattern will then be applied in the technician's time zone.
A shift is defined outside the context of any time zone; only when it is applied to the resource that will use it is the appropriate time zone context applied. Consequently, shift definitions are not affected by the availability of the user-preferred time zone feature.
If a time zone is not selected for a task, then all times will be in the corporate time zone. If a time zone is selected for a task, and user-preferred time zone support is enabled, then times appear in the selected time zone.
Although Bills of Material (BOM) calendars can be shared across facilities, the shift definitions are always defined in terms of the corporate time zone. Consequently, shift definitions are not affected by the availability of the user-preferred time zone feature.
There must be one calendar for each time zone in which manufacturing facilities are present. Facilities in the same time zone can share the same shift patterns. Facilities in different time zones will need their own shift definitions.
Complex Maintenance and Repair Operations (CMRO) users are advised to operate in the corporate time zone.
Accounting period start and end dates are stored and displayed in the corporate time zone. Users will be able to close an accounting period when the corporate time is past the scheduled close date indicated on the Inventory Accounting Periods form.
The Periodic Processors (Cost Processor, Acquisition Cost Processor, Acquisition Cost Adjustment Processor, Absorption Cost Processor, and Iterative Periodic Average Cost Processor) all require date fields to be input in corporate time.
The inventory position is built and displayed in the corporate time zone.
For creating consumption advice documents, the 'Create Consumption Advice' concurrent program uses the corporate time zone to aggregate consumption transactions based on transaction date.
Users have to enter and view Repetitive Production lines Start and Stop time fields (time only fields) in the corporate time zone.
In the WIP Lines form, users have to enter and view Flow Production lines Start and Stop time fields in the corporate time zone.
In the Kanban Planning form and the Graphical Kanban Workbench form, users have to enter and view all date times in the corporate time zone. Planning outputs (Forecast, MDS, and MPS) are bucketed in the corporate time zone. Kanban size and number of cards are calculated on the basis of demands from planning. Consequently, in order to maintain consistency with planning, Kanban planning calculates and displays in the corporate time zone.
In Mixed Model Map Workbench form, users have to enter and view all date times in the corporate time zone. Planning outputs (Forecast, MDS, and MPS) are bucketed in the corporate time zone. Resource and in-process-Kanban size are calculated on the basis of demands from planning. Consequently, in order to maintain consistency with planning, Mixed Model Map Workbench calculates and displays in the corporate time zone.
When defining release rules, users can define pick release rolling windows using the Schedule Ship Dates and Requested Dates. user-preferred Timezone, when enable for the user, applies to Release rules. When a user with a user-preferred time zone employs a release rule defined in the corporate time zone, the Scheduled Ship Dates and Requested Dates will be converted to that user's preferred time zone.
For example, if one user defines a Release Rule with a Scheduled Ship Date time of 9:00 AM in the corporate time zone, the same rule employed by another user will have the Scheduled Ship Date time converted to 9:00 AM in the second user's preferred time zone. Possible time zone implications should therefore be considered carefully when using the same release rule across multiple users in different time zones.
The Histogram, Control Chart, Pareto Chart, and Time Series Chart always use the corporate time zone to display the date and time quality collection elements on the axis labels.
If the user defined formula uses the date and time element from the server, the value will be in the corporate time zone, but if the formula uses the date and time element from the form field itself, the value will be in the user-preferred time zone (if set up).
The products in the Supply Chain Planning suite include Advanced Supply Chain Planning, Global Order Promising, Inventory Optimization, Collaborative Planning, Transportation Planning, and Material Requirements Planning. These products will display date/time fields in the corporate time zone only.
The planning products display business documents such as sales orders, purchase orders, and WIP jobs, which are all collected from execution modules such as Order Management, Purchasing, and Work in Process. Although these execution modules can display the business documents in a user-preferred time zone, within the planning user interface the date/time fields on these documents will be shown in the corporate time zone only. There is no Date/Time conversion when data is collected from ERP server to planning server or released from planning server to ERP server.
Some of the Advanced Planning products show views of supply, demand and resource capacity data bucketed into daily, weekly and period time buckets. These views of data are always shown in the corporate time zone.
The Global Order Promising product is integrated with Oracle Order Management. The user can enter a request date for a sales order within Order Management. This date, entered in the context of the user-preferred time zone within Order Management, is converted to the corporate time zone when performing an availability check against Order Promising (promise date on the sales order). The results of Order Promising are converted back to the user-preferred time zone when displaying within the Order Management screens.
Availability of the user-preferred time zone feature is not relevant to MRP since MRP date fields do not have a time stamp. MRP suggests completion dates to be the end of the day in the corporate time zone. If midnight in the corporate time zone happens to be during a working shift for the manufacturing plant, a job might be completed earlier or later than the expected date. This is not an issue for shop floor management (OSFM), as OSFM does not integrate with MRP.
Transportation Planning module supports location specific time zone. Review the Transportation Planning User Guide for details of the transaction-specific time zone support provided.
The Advanced Scheduler UI can work in User-Preferred time zone mode, but this is only suggested if all incident sites are located in the same time zone. If scheduling will be done to incident sites in different time zones, Incident-Based time zone support should be set up.
The horizon start date is pegged to the beginning of the day (in the corporate time zone), and the horizon end date is pegged to the end of the day (in the corporate time zone).
All dates are in a user-preferred time zone on this workbench, except for the dates in the Horizontal Demand and Horizontal Schedule windows: these are always shown in terms of the corporate time zone.
The CUM start date on CUM Workbench is always shown in the corporate time zone.
The horizon start date is pegged to the beginning of the day (in the corporate time zone), and the horizon end date is pegged to the end of the day (in the corporate time zone).
In OPM Financials, the following processes are scheduled in the user-preferred time zone:
Cost Rollup Process
OPM Accounting Pre-Processor
Actual Cost Process
Cost Update Process
The start and end dates of the OPM Accounting Pre-Processor are stored and displayed in corporate time zone.
Oracle E-Records operates in the corporate time zone, and all transactions are recorded and displayed in this time zone. The profile option 'EDR: Server Time Zone' must be set to the corporate time zone. If this value is not set, no events can be raised, and an error indicates that all e-records have a null value for the time zone.
In Oracle Financials, most dates simply bucket transactions into financial periods. Although these dates are often derived from actual transaction dates and times, these dates merely act as pointers to a financial period, rather than to an actual point in time. Conversions do not occur on such date fields. Consequently, use of user-preferred time zones has no effect on how financial documents and GL transactions are viewed and processed.
As with accounting dates, the effective dates for currency conversion rates simply point to a day (or set of days) within an accounting period, and define the conversion rate that is used for transactions bucketed into that day (or set of days). Date conversions do not occur on conversion rate effective dates. Consequently, use of user-preferred time zones has no effect.
When a transaction date with time is captured on a subledger transaction, such as a shipping date or purchasing receipt date, it is viewed in the user's preferred time zone. When these transactions flow into Financials, the transaction dates, in reference to the corporate time zone, are often used to derive the accounting dates. The accounting dates are also shown in the corporate time zone rather than the user's preferred time zone. These dates indicate the period into which the transaction will be posted, rather than the actual date on which the transaction occurred.
When drilling down from a financial document into the subledger transactions, users should be aware that the accounting dates are relative to the corporate time zone and will be shown as such, whereas some subledger transaction dates will be shown in the user's time zone
In Oracle Human Resources, all objects that have the DateTrack feature (such as benefit plans or element types), use dates globally, without a time component. This means that, for example, the date associated with a benefit plan is relative to the time zone in which the benefit plan is used. Therefore, if a benefit plan is set up to start on 1st January, it will start on this date wherever it is used in the world.
Where entering dates and associated times in separate fields in Oracle Human Resources products, these dates and times are not affected if user-preferred time zone support has been enabled. User-preferred time zone support only affects dates that have a time component within the same field. These dates and times apply either to the local time zone in which they were entered, or to a context-specific location time zone. For example, the start and end times of an applicant interview are relative to the location of the interview.
The following sections describe the time and date behavior specific to Human Resources.
This section describes the features specific to Human Resources that are affected if user-preferred time zone support has been implemented.
The Employee Details page of the Self-Service Employee Directory displays the local time at the worker's location.
The Server Timezone profile option should be set to the time zone corresponding to the server time zone. The Employee Details page will then display the correct local time for the worker's location.
To use this feature without allowing user-preferred time zone support to be enabled for other windows and pages, carry out the following steps:
Prevent the Client Timezone profile option being set at the user level. For more information on profile options, see Oracle E-Business Suite Developer's Guide and Oracle E-Business Suite Security Guide.
Use the Personalization Framework functionality to remove the Time Zone field from the Preferences page.
When changing the status of an application in iRecruitment, the system records the exact date and time of the change as of the user-preferred time zone. However, if a retrospective status change is made, the system sets the date and time as the start of the day (midnight) of the standard corporate time zone.
When viewing the Application Status History, iRecruitment converts the date and time recorded for each status change to the user-preferred time zone.
The start and end collection parameters that use date only will display the date in the standard corporate time zone. These processes collect data from the start of the specified Start date to the start of the specified End date, as per the corporate time zone.
These parameters are unaffected by user-preferred time zone support.
The time displayed in the parameters that display date and time is in the user-preferred time zone. The application converts the time to the standard corporate time zone before storing and running the program on the server.
Use of a user-preferred time zone can lead to unexpected results in some circumstances. For example, if the server is in the Pacific time zone, and a user enters a Collect To value of 03-JAN-2013 0700 in London (8 hours ahead), this represents 02-JAN-2013 at 2300 in the Pacific time zone. This discrepancy leads to the concurrent program collecting data up to the start of 2nd January, instead of up to the start of 3rd January as expected.
The following features are unaffected if you implement user-preferred time zone Support. This section clarifies how dates and times in Human Resources products behave, whether or not user-preferred time zone support is enabled.
If the user profile DateTrack:Login Date (YYYY/MM/DD) has not been set, the Effective Date defaults to the date of the standard corporate time zone, as of the time the user logs into the HRMS application.
A user with security privileges can use the Alter Effective Date window to change the Effective Date. The Effective Date may need to be changed if the application is used in a time zone that is sometimes in a different date from the standard corporate time zone.
All DateTrack effective start and end dates have no time component. Therefore, no time zone adjustment is possible.
When an employee enters start and end times in the Timecard Entry and Timekeeper windows, these times are for the local time zone in which the employee actually worked. Therefore, a manager reviewing a Timecard can assume that the time shown on a Timecard is for the local time at the working location . This may be different from the worker's assignment location: for example, a worker may normally work in Los Angeles, but be called away to New York . For this reason, Timecard Entry and Timekeeper do not use the assignment's location time zone, since this does not account for people working away from an assignment location. This behavior is contrary to the behavior if user-preferred time zone Support is enabled, which displays times in the user's preferred time zone.
For daylight savings adjustments to be calculated accurately in the Self-Service Timecard Entry screen, the application server time zone should be set to a time zone that includes daylight savings adjustment similar to the user time zone.
When creating a shift pattern, start and end dates are not supplied. This enables a single shift pattern to be applied to a date in any location. A date is associated with a shift when a working shift pattern is assigned to an employee. The start and end times of the shift then apply to the time zone in which the employee works the shift.
A location can optionally be associated with a specific time zone. If a time zone is set for a location, some windows display the time zone: the times displayed in such windows are in the location time zone.
The following windows do not display dates and times in the user-preferred time zone, but in a context specific time zone, as described below for each window.
The Employee Review window has a Time Zone field. When selecting a location for the employee's review, the Time Zone field displays the time zone associated with that location. The review start and end times are in the location time zone, regardless of your location or the user's preferred time zone.
The start and end times are in the time zone of the interview location.
The windows display the event's start time and end time, along with the event's location. The event times are in the time zone of the event location.
This window displays the Project start and end dates and times, and the Actual start and end dates and times. These dates and times are in the time zone in which the employee works.
This window displays the Incident and Reporting dates and times in the time zone of the incident and reporting locations.
A number of windows display Normal Working Start and End Times. These include:
Application
Position Description
Organization, as Work Day information
Employee Assignment, on Standard Conditions
As these are time-only values, the time zone depends on the context in which the times are used. For example, an employee in New York could have the same position as an employee in Los Angeles . If the position start time is 0900, this is 9 am New York time for the worker in New York , and 9 am Los Angeles time for the worker in Los Angeles. These windows will not display times in the user's preferred time zone, even if user-preferred time zone support is enabled.
All dates with a time component that display in the Approvals Management user interface are as of the standard corporate time zone. They are not affected by how the Time Zone profiles are set.
Whenever a future-dated rule is created or updated, it will be effective from the start of the day (midnight) as of the standard corporate time zone. Therefore, future-dated rules come into effect at the same point in time for all time zones, irrespective of when midnight occurs in each time zone.
When creating or updating a rule that is not future-dated, the rule comes into effect immediately, regardless of time zone. All future transactions (worldwide) are affected from the moment the rule is created or updated, regardless of the time zone of the transaction.
Learning Management organizes classes and events for specific dates and times. The following Learning Management windows and pages display date and time information based on the event location, rather than the user-preferred time zone:
Development Event
One Time Event
Resource Booking (Other Details tab)
Sessions window (PUI)
Sessions page (OAF)
The following Learning Management windows also display date and time information:
Self-Paced Class
Scheduled Class
The date and time in these windows is based on the time zone of the class. The Learning administrator enters the class time zone when creating the class.
Oracle iStore displays date/time in the corporate time zone only, and iStore UIs display the corporate time zone context when the user-preferred Time Zone feature is enabled at your site. For more information, refer to My Oracle Support Knowledge Document 403414.1, Oracle iStore Documentation Resources, Release 12.
There are no upgrade considerations for E-Business Suite customers upgrading from 11.5.10 CU2 or higher who have already enabled user-preferred time zone support. The upgrade will be transparent and the relevant functionality will not change.
For E-Business Suite customers who are upgrading to Release 12.2 from a release in which the user-preferred time zone feature was not enabled or not used, existing time zone practices must be taken into account when enabling user-preferred time zone support.
Prior to Release 11.5.10 (with CU2), users could deal with time zone differences in one of two ways:
By entering data in the standard corporate time zone (as recommended by Oracle).
The choices in this case are between:
Enabling the user-preferred time zone feature and allowing users to continue working in the standard corporate time zone (as before the upgrade)
Enabling the user-preferred time zone feature, setting a preferred time zone, and starting to interact with the system in this time zone. Failing to set a user-level time zone preference at user level will result in the standard corporate time zone continuing to be used.
By entering data in the local time zone, and using a custom solution to resolve any issues that arise when comparing data across transactions initiated in different time zones.
In this case, enabling the user-preferred time zone feature could result in unwanted date-with-time conversions, whereby local dates with time are converted to the user-preferred time zone: this is because the system assumes that all dates with time are stored in the corporate time zone.
For further details, refer to Oracle E-Business Suite Upgrade Guide: Release 11i to Release 12.
This section provides the technical considerations involved in implementing the user-preferred time zone feature.
For user-preferred time zone support to operate correctly, all of the following must be true:
The operating system time zone setting for the database server must be set to the standard corporate time zone.
The database must be configured to use the time zone file timezlrg.dat rather than the timezone.dat file.
The database must be started in the standard corporate time zone.
Every application tier JVM (Java Virtual Machine) must be started in the standard corporate time zone. This can be achieved by setting the application tier operating system time zone to match the standard corporate time zone.
Profile 'Server Timezone' (SERVER_TIMEZONE_ID) must be set at site level, and must be set to the same standard corporate time zone as the database.
Profile 'Client Timezone' (CLIENT_TIMEZONE_ID) must be set at user level. This is applicable to Oracle Forms based UIs.
Preference 'Timezone' must be set at user level. This is applicable to HTML based UIs.
Profile 'Enable Timezone Conversions' (ENABLE_TIMEZONE_CONVERSIONS) must be set to 'Yes' (or 'Y') at site level.
Profile 'Concurrent: Multiple Time Zones' (CONC_MULTI_TZ) must be set to 'No' (or 'N') at the site level.
Environment variable FORMS_APPSLIBS must be set in the Forms tier
Forms must be launched through the Personal Home Page or Navigator portlet.
These requirements are discussed in more detail below.
The database must be started using the timezlrg.dat file, which contains the time zone definitions that are used within Oracle E-Business Suite. To do this in a UNIX environment, issue a command such as:
setenv ORA_TZFILE $ORACLE_HOME/oracore/zoneinfo/timezlrg.dat
before starting the database.
The database must also be started in the standard corporate time zone. To set this in a UNIX environment, issue a command such as:
setenv TZ <Timezone Code> [For example, 'America/Los_Angeles']
You can verify your setup by running the following command in SQL*Plus:
select to_char(SYSDATE, 'DD-MON-RRRR HH24:MI:SS') from dual;
to ensure the date with time returned are correct for the corporate time zone.
The profile option Server Timezone (SERVER_TIMEZONE_ID) should be set at site level to the standard corporate time zone (the time zone in which the server has been set to run).
Caution: This profile option should not be changed once set, as existing data will not be updated.
Users may specify their preferred time zone at user level. This is done by setting the 'Timezone' preference in HTML-based applications, or by setting the 'Client Timezone' profile option in Forms-based applications. As with most profile options, the user will need to log out and log back in for the change to take effect. The preferred time zone may be changed as often as needed.
The profile option 'Enable Timezone Conversions' (ENABLE_TIMEZONE_CONVERSIONS) has a default value of 'No' at site level. This will cause the applications to continue showing all dates in the corporate time zone. Setting this value to 'Yes' will enable the automatic conversion of all date with time fields to the user-preferred time zone.
Important: Unless users are notified of this change, they may think that they are still operating in the corporate time rather than local time (or vice versa), and consequently enter or interpret data erroneously.
Note the behavior of the existing profile 'Concurrent: Multiple Time Zones' (CONC_MULTI_TZ). This was an older feature to handle batch processing. Setting this profile to 'Yes' alters the default value that appears for the Scheduled Start Date in the Submit Requests screen to SYSDATE-1. With the new user preferred time zone feature enabled, this profile is no longer needed, and should have a value of 'No'.
This environment variable controls multiple aspects of Oracle Forms in the Oracle E-Business Suite environment, and must be left unchanged from the installed setting.
The time zone feature is only available in Oracle Forms based user interfaces within Oracle E-Business Suite when the user logs in through the Personal Home Page or the Navigator portlet. Direct launching of Forms, for example by typing a URL into the browser address line, is supported only for bootstrap purposes, and will not enable the time zone feature, or other features such as language settings and date formats.