Summary

The Date and TimeofDay property types — unlike the DateTime property type — do not identify a time zone. Although Process Commander can extract a DateTime property to a Date or TimeofDay value directly, it is often preferable to use a standard function rule that is sensitive to the time zone. As a best practice, use DateTime values in persistent objects, converting the values to local time-zone specific values only for presentation to users. 

Suggested Approach

Every DateTime property value has the Coordinated Universal Time format yyyyMMddtHHmmss.SSS zzz, where:

• yyyy is the year
• MM is the month value, from 01 to 12
• dd is the day within the month (01 to 31)
• T or t is a single letter
• HH is a hour (01 to 23)
• mm is minutes (01 to 59)
• ss is seconds (01 to 59)
• a period (stop) character separates seconds from milliseconds
• SSS is the milliseconds value (000 to 999)
• zzz is "GMT" , indicating the value is always based on the 0 time zone, informally known as Greenwich Median Time or Zulu time.

In contrast, a Date property value has the format yyyyMMdd (for example 20070707) and does not include a time zone. Similarly, a TimeofDay property value has the format HHmmss (for example 125857 for 57 seconds after 12:58 P.M. ) and does not indicate a time zone.

Conversions by default (substring)

Using the Property-Set method or similar built-in expression processing, you can convert a DateTime property value to a Date property value or to a TimeofDay value automatically. For example, if property MyDate has a type of Date, and property MyTime has a type of TimeofDay, this activity step converts the DateTime value for December 1, 2007 at 1:15 A.M:

The MyDate result is 20071201. The MyTime result is 011523. These two results are valid for Greenwich (and so for London).

But in New York, this pxExpireDateTime value corresponds to November 30th, not December 1! And the time is 8:15 PM. In many situations, December 1 at 1:15 A.M. do not represent the expected or intended results.

Extracting a date considering time zone

Use the standard function FormatDateTime() with a Java date pattern as the second parameter to make such conversions properly, relative to your server's time zone. For example:

If the Process Commander server is in New York (and is operating on Eastern Standard Time), this step results in a MyDate value of 20071130 and a MyTime value of 201523.

Optionally, you can specify a time zone code as the third parameter to the FormatDateTime() function, for example:

     @FormatDateTime(.pxExpireDateTime, yyyyMMdd, "MET", "")

for Middle European Time, corresponding to Paris and Berlin.

Extracting only for user presentation

Because DateTime values remain correct even when a Process Commander server or database is relocated, or when an application built for a single time zone is expanded to serve users or customers in multiple zones, they are preferable for internal operations. Using a Date value, a TimeofDay value, or both, may save a few bytes, but at the penalty of a serious loss of information that may be needed later — the time zone basis.

As a best practice, use DateTime properties rather than Date or TimeOfDay properties in work objects, assignments, and other persistent objects. Format or extract date values or time of day values only for user input and output. Some special cases (a birth date, a daily closing time) are typically relevant only in a specific place (where the person was born, closing time at the Boston office) where the time zone is implicit.

For more information, consult the Help System topic Understanding the Date, Time of Day, and DateTime property types.