Title: Data Item Class jdeutime

Дата канвертавання27.04.2016
Памер17.22 Kb.

Title: Data Item Class JDEUTIME

Abstract:  This document provides an overview of a date/time data item class, new with PeopleSoft EnterpriseOne 8.9.  This data type has both a date and time component and performs all date and time calculations in Coordinated Universal Time.

Table of Contents

1. Overview of Issue

2. Solution

3. Formatting and Display Characteristics

4. New APIs and Event Rule Functions Associated with Universal Time 

Overview of Issue

Prior to PeopleSoft EnterpriseOne 8.9, the software presumed that all users of a system were located in the same time zone.  While this is not a problem for localized enterprises dealing with only one time zone, it becomes a significant issue for enterprises whose business processes span several time zones, particularly when the duration of these processes is relatively short.  Time zone variations make timestamps inaccurate, and the potential errors caused by these variations can make the calculated and reported dates in applications almost meaningless.  In the current e-business environment, where multi-zone, short duration business processes are typical, finding a solution to this problem is critical. 

In order to provide some clarity, lets look at a real example.  For this example lets have the enterprise server in Denver (GMT -7) and a user located in Sydney, Australia (GMT +10). There is a 17-hour difference between these two locations. This 17-hour difference means that Denver and Sydney share the same date for only a 6-hour period of time.  If the user in Sydney enters a new Sales Order in P4210 on October 13, 2003 at 11:00AM, this corresponds to October 12, 2003 at 6:00PM in Denver.  If the Denver office then runs a Sales Order Update at 10:00PM on October 12, to update all the sales order for that day, it will miss the Sydney order as its date stamp (October 13) is in the future.  This means that this sales order would not be updated until the next day in Denver. If you reverse the enterprise server and the user, then we have the possibility of this sales order never getting updated at all by the Sales Order Update process. 

Lets look at one more Sales Order Entry example where time would be important with respect to a date.  In this example a user is taking a sales order in Denver for a Customer in Australia.  As part of this process we need to calculate when the package will arrive at the customer site.  The order is placed on 10/13/03 at 5:00 PM in Denver, which for the Australian customer is 10/14/03 at 10:00 AM.  Lets assume that we know this package will be picked up, by the delivery service in Denver, on the morning of 10/14/03 at 9:00 AM, and that delivery will take three working days.  If we are cognizant of time zone information, we will correctly calculate the delivery date as 10/18/03.  Without time zone information, the customer would be expecting the package on 10/17/03.

These examples highlight the need for applications to be aware of time information when working with dates.  This awareness of time is more important for calculating dates, than it is for knowing an exact time.  However, time information becomes extremely important when creating audit information.  In a global enterprise, the ordering of transactions based on audit information is critical. In order for the audit information to be useful it must be stored with finer resolution than just date.  This is why exact times must be used, but for this time to be useful it must be relative to a single reference point.  This is exactly what Universal Time was designed for.  All times are relative to a single reference point, thus eliminating any confusion resulting from different time zones. 

Back to Top


A new data type, JDEUTIME, has been created.  This data type has both a date and time component.  This new data type stores all dates/times, and performs all date/time calculations, in Coordinated Universal Time (UTC).  When a user runs an application, and enters a date/time, it will internally be converted to UTC and stored in the database as UTC.  When another user then inquires on this date, it will be fetched from the database and then converted to the user’s local time based upon the user’s personal profile, or to a UTC offset specified by the application (e.g. the customer’s time zone, or a business unit’s time zone) before being displayed.  This conversion will be transparent to both the application and the user. 

Coordinated Universal Time (UTC) is in essence the new name for Greenwich Mean Time (GMT), which is based upon the time at the zero degree meridian that crosses through Greenwich, England. UTC is a worldwide standard consisting of 24 time zones starting at UTC -0, which passes through the zero degree meridian.  UTC time zones decrease from UTC -1 to UTC -12 heading west, and increase from UTC +1 to UTC +12 heading east. The United States time zones range from UTC –5 (Eastern Standard Time) to UTC – 8 (Pacific Standard Time).

There aren’t any standard data items in class JDEUTIME that are used in any standard reports or applications with PeopleSoft EnterpriseOne 8.9, but the data item is available for use in custom or modified objects.  Use data items in this class like any other data dictionary item is used.   
Back to Top

Formatting and Display Characteristics 

  • JDEUTIME stores a date and time with accuracy to the second.

  • The date/time will always be stored and manipulated at UTC –0:00.

  • A user’s time zone and time format are set up in their user profile.

  • If no time is entered, 00:00:00 is assumed.

  •  If no time zone is entered, then the user’s time zone is used.

  • When JDEUTIME is displayed, it will be shifted to a given UTC offset.

  • A JDEUTIME string will have the following format:   DATE TIME OFFSET è 1/1/2003 12:00:00 AM (UTC –7:00)

  • DATE can have any of the current JDEDATE formats.

  • TIME can be in 12-hour format as shown above, or if there is no AM or PM, 24-hour format is assumed.

  • TIME can be entered with or without seconds, but will always be displayed with seconds.

  • OFFSET can be between -12:00 and +12:00, in 15-minute intervals.


Back to Top

New APIs and Event Rule Functions Associated with Universal Time 


JDEUTIME can only be manipulated by using the associated APIs.   APIs exist to:

  • Parse a JDEUTIME string

  • Format a JDEUTIME for display

  • Set a JDEUTIME

  • Get individual components of a JDEUTIME

  • Perform JDEUTIME calculations, conversions, and comparisons



Event Rule Functions


There are new event rule functions available within the Expression Manager in event rules that were designed for use with the JDEUTIME data item.  Some of these functions are listed below.       

utc_get_cur_time( )

    Returns a JDEUTIME set to the current time

utc_get_year(utime, time zone)

    Returns the year of the passed in JDEUTIME in the given time zone

    If a NULL time zone is passed in then the current display time zone is used, if there is no display time zone, then the user's time zone

    is used.

utc_add_years(utime, amount)

    Returns a JDEUTIME with the given number of years added to the passed in JDEUTIME

utc_days_between(utime, utime)

    Returns the number of days between two JDEUTIMEs

utc_last_day(utime, time zone)

    Returns a JDEUTIME set to the last day of the month of the passed in JDEUTIME, but displayed in the passed in time zone

change_disp_tz(utime, time zone)

    Returns a JDEUTIME set to the same time as the passed in JDEUTIME, but displayed in the passed in time zone

get_users_tz( )

    Returns a string representing the time zone that the user has set up in their user profile


Back to Top

Bottom of Form

Bottom of Form

База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка