This appendix describes how date and time behave and are configured in Oracle BAM.
It contains the following topics:
All of the data that is sent to Oracle BAM is stored in oracle BAM data objects in the server time zone.
Oracle BAM Architect displays data in the server time zone.
The data in filters and prompts is also in the server time zone by default.
Time zone setting in the Active Studio and Active Viewer personalize dialog is used by default to transform times from Oracle BAM Server time to the preference of the user in their locale.
Time-based alerts always use the time zone settings configured in the user preferences.
Reports may define their own date pattern and transformation, or use the time zone settings configured in the user preferences.
All display of dates in the Web browser is formatted as per the Web browser locale.
For alerts that e-mail reports to users, there is no Web browser in the use case, so the user preference is used for formatting.
A Time Zone preference can be set in the Personalize dialog in Oracle BAM Active Studio and Oracle BAM Active Viewer. This feature helps to maintain the default preference for a user. A user can set any one of the following:
GMT for reports and locale time zone for alerts.
Your locale time zone (Asia/Calcutta).
Choose a time zone preference.
A user can also indicate if the time should be adjusted for daylight savings.
The user's indicated Time Zone preference in is used for displaying time in reports and time-based alerts.
In reports, this is applicable only when a report contains datetime data in GMT, and value formatting is specified as Each users time zone preference.
In time-based alerts, if time zone preference is not set, then it would be set to the Web browser's locale time zone for that user, and the alert also provides a link to override the default setting.
No date or time transformation is done to the date column values if there are no settings specified in "Value Format".
Pattern and transformation can be overridden using "Value Format":
Date pattern (e.g. m/d/yy or MM/dd/yy H.mm.ss or Long date and time ...) for date columns can be defined using "Value Format".
Date transformation (adjust from GMT) for date columns can be defined using "Value Format". One out of the following options can be selected for transformation:
Each users time zone preference.
Each browser's locale time zone.
Specific user defined time zone selected from a predefined list.
A user can also mention if the transformation should take daylight savings time into account.
Dates are transformed as per user preference in prompts.
In filter expressions, dates are input in default time zone, as it is displayed in Oracle BAM Architect. Dates are transformed as per user preference in prompts.
Alerts UI displays Date-Time in user preferred time zone, and formats it according to the locale setting of the user's browser. User can set his time zone settings for alerts from the "Personalize" link in Active Studio/Active Viewer/Architect.
If there is no time zone set for for a particulr user, it is set to his local time zone when he first tries to access the Alerts editor to create or edit an alert.
If the alert has been configured to run as a different user (using the "Run As" feature), time zone setting of the "Run As" user will be considered. Again, if the "Run As" user does not have Alerts time zone preference, set, current user's (alert creator's) local time zone will be set as his alerts time zone preference.
Formatting of date-time in Alerts UI is as per the user locale (locale set in user's browser).
EMS has the ability to parse the date time values of the incoming payload. One can define the parsing format or resort to default parsing in the DateTime Specification section of the EMS definition configuration.
Pattern is specified by using the pattern letters (Note that this pattern and Locale specification is used to construct a java.text.SimpleDateFormat Java object).Locale is specified by providing the following three sub-specifications (refer to java.uitl.Locale class definition for further details):
Language: This should be lowercase two-letter ISO-639 code (for example, en, fr, de, it).
Country: This should be uppercase two-letter ISO-3166 code (for example, CN, TW, FR, DE).
Variant: This can be vendor or browser specific code. For example, use WIN for Windows, MAC for Macintosh, and POSIX for POSIX. Where there are two variants, separate them with an underscore, and put the most important one first. For example, a Traditional Spanish collation might construct a locale with parameters for language, country and variant as es, ES, Traditional_WIN.
Based on whether pattern and/or Locale are specified or not, we have the following implementation:
|Pattern Specified||Locale Specified||Implementation|
Provided pattern and Locale will be used to construct a SimpleDateFormat object and it will be used in the parsing of source fields in DateTime format.
Same as above except that default Locale (i.e., Locale.getDefault()) will be used.
yyyy#MM#dd#hh#mm#ss#SSS where "#" can be any of the following separators:
T (capital T)