Search Results get_server_timezone_details

Overview

APPS.ECE_TIMEZONE_API is a public PL/SQL API distributed with Oracle E-Business Suite that provides a centralized, server-side mechanism for time zone conversion. It resides in the APPS schema and is declared with AUTHID CURRENT_USER, meaning that it executes with the privileges of the calling user rather than the definer. This design allows any EBS module or custom code to invoke the API without requiring EXECUTE grants on the underlying objects owned by the APPS schema, while still enforcing the caller's own security context.

The package addresses a recurring requirement in the E-Business Suite: dates stored in the database are frequently recorded in a source time zone (often server time, GMT, or a user's local time) but must be presented or processed in a different target time zone. Rather than embedding time zone arithmetic in individual forms, concurrent programs, or interfaces, developers can call this API to obtain a converted date. The package exposes two documented procedures, GET_SERVER_TIMEZONE_DETAILS and GET_DATE, the latter of which is the focus of the search term "get_date".

Key Procedures and Functions

• GET_DATE — Converts a supplied source date from its originating time zone into a specified destination time zone. The caller provides the source date (p_src_date) and the target time zone name (p_timezone_name), and receives the converted date through the x_dest_date output parameter. This is the procedure most commonly referenced when developers search for "get_date", because it is the single entry point for performing an actual time zone conversion within the package. It is typically used to normalize a timestamp for display or comparison against a value expected in a particular zone.
• GET_SERVER_TIMEZONE_DETAILS — Returns details about the time zone configured for the application server. Given an input date (p_date), it returns the GMT deviation (x_gmt_deviation) and the global time zone name (x_global_timezone_name) in effect for that date. This procedure is useful for determining the server's current offset from GMT, which can change with daylight saving transitions, and for obtaining the canonical time zone name that can subsequently be passed to GET_DATE.

Tables Accessed

The ETRM metadata for this package does not enumerate any base tables referenced through APPS synonyms. The package is a lightweight utility API whose logic is expressed through the two procedures above; any internal lookups of time zone definitions would be resolved through the standard EBS time zone infrastructure rather than through documented, package-owned table access. Consumers should therefore treat ECE_TIMEZONE_API as a computational service and not as a data-retrieval package. No direct read or write of application tables is exposed through its public interface.

Usage Notes

Because the ETRM record states that the package is referenced by two other packages, it functions as a shared dependency within the EBS code base rather than as a standalone application entry point. It is not associated with a form or concurrent program of its own; instead it is invoked programmatically from PL/SQL.

Typical invocation patterns include:

• Custom PL/SQL packages and interfaces that must reconcile dates captured in different time zones.
• Concurrent program logic that compares a stored date to a user-entered date expressed in a specific zone.
• Forms or OAF pages that call server-side code to convert a stored date before display.

When calling GET_DATE, the developer should first establish the correct target time zone name, which can be obtained via GET_SERVER_TIMEZONE_DETAILS for server-oriented conversions or supplied directly for user-oriented conversions. Both procedures use NOCOPY OUT parameters for performance, and no return value is provided, so error handling should rely on standard PL/SQL exception propagation. The package is available in both EBS 12.1.1 and 12.2.2, and its header indicates a stable API revision dating from 2005, underscoring that its interface is intended to remain backward compatible.