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
Solution
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, 24hour 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
APIs
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