Kbase P122322: 4GL/ABL: The STRING function uses the DST rules.
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
01/10/2008 |
|
Status: Unverified
SYMPTOM(s):
4GL/ABL: The STRING function uses the DST rules.
The STRING function is expected to simply trim the TIME ZONE part and not use the DST rules.
Running the following code on Windows XP with the 2007 DST patch applied returns different hour parts:
DEFINE VARIABLE v-dt-tz-2006-02-28 AS DATETIME-TZ NO-UNDO INITIAL 2006-02-28T11:14:03.002-05:00.
DEFINE VARIABLE v-dt-tz-2006-03-15 AS DATETIME-TZ NO-UNDO INITIAL 2006-03-15T11:14:03.002-05:00.
MESSAGE
STRING(v-dt-tz-2006-02-28,"99/99/9999 HH:MM:SS.SSS") SKIP
STRING(v-dt-tz-2006-03-15,"99/99/9999 HH:MM:SS.SSS") SKIP(2)
VIEW-AS ALERT-BOX.
The hours part on both lines of the above message are expected to be the same but they are not.
FACT(s) (Environment):
All Supported Operating Systems
OpenEdge 10.1x
CAUSE:
Bug# OE00146633
CAUSE:
This issue is Windows XP specific when the 2007 DST patch applied. On Windows XP, there is only one definition of DST (year independent) and it applies to the past and future, so since Progress changed for 2007, items from the second Sunday of March to first Sunday of April in previous years could be off, because they are considered to be in the extended DST period, even though that year never had it. This is functioning as designed according to Microsoft.
FIX:
This is working as designed. On non Windows Operating Systems the hours are the same as expected. The STRING function indeed uses the DST rules just like the DISPLAY statement. The STRING function takes a DATETIME-TZ and converts to a character value, and considers DST rules just like the DISPLAY statement does. When the time zone part is omitted from the display format, the DATETIME-TZ is converted to a local date/time relative to the sessions offset on the date/time of the DATETIME-TZ value.