How to extract a DateTime value to a Date or Time of Day value
TimeofDay property types — unlike the
DateTime property type — do not identify a time zone. Although Process Commander can extract a
DateTime property to a
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.
DateTime property value has the Coordinated Universal Time format
yyyyMMddtHHmmss.SSS zzz, where:
yyyyis the year
MMis the month value, from 01 to 12
ddis the day within the month (01 to 31)
tis a single letter
HHis a hour (01 to 23)
mmis minutes (01 to 59)
ssis seconds (01 to 59)
- a period (stop) character separates seconds from milliseconds
SSSis 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
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
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.