Search Results string_to_date

Overview

FND_CONC_DATE is a small utility package in the Oracle E-Business Suite Applications (APPS) schema whose responsibility is concurrent-processing date handling and, more specifically, the conversion of date strings supplied by users or concurrent program parameters into native Oracle DATE values. It is an internal, low-level helper rather than a business-facing API; the ETRM classification of OTHER reflects that it exposes no workflow, interface, or entity lifecycle operations. Its two public subprograms, STRING_TO_DATE and GET_DATE_FORMAT, exist to centralise the interpretation of date strings against the session's National Language Support (NLS) conventions, so that callers do not each have to re-implement locale-sensitive parsing logic.

The package is declared with AUTHID CURRENT_USER, meaning its procedures execute with the privileges of the invoking schema rather than as the definer. This is consistent with a utility package intended to be called from within the APPS environment where the caller already holds the necessary synonyms and grants.

Key Procedures and Functions

• STRING_TO_DATE — The function most relevant to the search term string_to_date. It accepts a character string (declared string in varchar2) and returns a DATE. Its purpose is to interpret an arbitrary date-formatted string and produce the corresponding Oracle DATE value, applying the appropriate session date format. The accompanying pragma restrict_references (STRING_TO_DATE, WNDS) asserts that the function writes no database state, confirming it is a pure read/convert operation. Because the metadata documents no further parameters, callers should expect a single-input, single-output conversion with no error-out argument; conversion failures manifest as standard Oracle date-conversion exceptions, which the caller must trap.
• GET_DATE_FORMAT — Accepts a character string and returns a VARCHAR2. It retrieves/determines the date format string that is in effect for the given input, allowing callers to discover the session's expected date mask before or alongside conversion. It too carries pragma restrict_references (GET_DATE_FORMAT, WNDS), so it is read-only. It pairs naturally with STRING_TO_DATE: a caller can obtain the applicable format and then perform the conversion consistently.

Both routines are declared at the top of the package specification and constitute the entire public interface (two functions in total); no additional documented procedures exist.

Tables Accessed

The only documented table reference, reached through an APPS synonym, is NLS_SESSION_PARAMETERS. This is a dynamic performance / NLS view that exposes the current session's language, territory, and date-related settings. FND_CONC_DATE queries it to establish the active NLS date format so that STRING_TO_DATE and GET_DATE_FORMAT honour the user's locale instead of assuming a hard-coded mask. No application data tables are read or written, which is consistent with the WNDS purity pragmas on both functions and the package's classification as a utility converter.

Usage Notes

FND_CONC_DATE is typically invoked indirectly. It is referenced by 15 other packages according to the ETRM metadata, indicating that it serves as a shared conversion primitive across the concurrent manager and related date-processing code rather than being called directly by end users. Practical invocation scenarios include:

• Concurrent program parameter post-processing, where a user-entered or submission-defaulted date string must be normalised to a DATE before being passed to a program's logic.
• Internal use by other APPS packages that need locale-aware date parsing without duplicating NLS lookups.
• Custom code extending EBS, where a developer requires the same conversion semantics used by standard concurrent date handling.

Because the package relies on NLS_SESSION_PARAMETERS, callers should be aware that results depend on the effective session NLS settings; behaviour may differ between sessions with different language/territory environments. As a read-only utility it is safe to call from within queries and PL/SQL, provided the DATE-conversion exceptions are handled by the caller. Its presence across 12.1.1 and 12.2.2 is unchanged, as evidenced by the identical source header and specification.