In 4GL, specific formats for integer values can interpret them as time. This feature is likely kept for backward compatibility, from a time when no dedicated time types were available, making this the only way to format time values.

Per the Progress documentation:

If source is an integer and format begins HH:MM or HH:MM:SS, STRING formats the source as a time. If the hour is greater than or equal
to 12 and there is an A or an a in format, STRING subtracts 12 from the hour and converts the A or the a to a P or p (for A.M. and P.M.).
The hour 0 is treated as 12 a.m., and noon is treated as 12 p.m. If you use AM/PM format, HH is replaced by a leading blank and a digit if the hour is between 0 and 9.

   format(1, "+hh:mm") = +00:01
   format(1, "+hh:mm:ss") = +00:01:00
   format(1, "hh:mm") = 00:00
   format(1, "hh:mm:ss") = 00:00:01
   format(13 * 60 * 60 + 2 * 60 + 3, "hh:mm:ss") = 13:02:03
   format(13 * 60 * 60 + 2 * 60 + 3, "hh:mm:ssa") = " 1:02:03p" 
   format(13 * 60 * 60 + 2 * 60 + 3, "hh:mm:ss a") = " 1:02:03 p" 
   format(13 * 60 * 60 + 2 * 60 + 3, "hh:mm:ss A") = " 1:02:03 P" 
   format(3 * 60 * 60 + 2 * 60 + 3, "hh:mm:ssA") = " 3:02:03A" 
   format(0 * 60 * 60 + 2 * 60 + 3, "hh:mm:ssA") = "12:02:03A" 
   format(13 * 60 * 60 + 2 * 60 + 3, "hh:mm:ss A") = " 1:02:03 P" 
   format(24 * 60 * 60 + 2 * 60 + 3, "hh:mm:ss A") = "12:02:03 A" 
   format(13 * 60 * 60 + 2 * 60 + 3, "hh:mm:ss qweAAA") = " 1:02:03 qwePAA" 

These formats are valid only for integers. When applied to decimal values, they are processed as standard numeric formats, resulting in relevant errors.

The Issue¶

Run this 4GL example::

  STRING(1, "+hh:mm:ss").

Expected result: +00:01:00.
FWD result: 1h:mm:ss.

It seems FWD does not recognize the special format and formats the integer value incorrectly as a regular number.

When an integer value exceeds the format's limit, the excess should be discarded. However, FWD fails to do this, allowing hours to exceed 23.

Example::

  STRING(1000 * 60 * 60 + 2 * 60 + 3, "+hh:mm").

Expected result: +02:03.
FWD result: +60002:03.

Related Issue¶

The code::

  STRING(1.0, "+hh:ss").

should trigger error 22, as decimal values are not supported with time formats. Instead, FWD does not raise an error and outputs 1h:ss, which is illogical.

FWD seems to avoid formatting decimals as time but does not properly detect invalid formats. This issue is already covered in #10075.

The TestIntegerFormattedAsTime class added to the testcases at rev. 1801. All tests pass with 10471a.

Vladimir Tsichevski wrote:

The updated ABLUnit test class TestIntegerFormattedAsTime.cls is included as an attachment.

What has changed:

1. A specialized method was introduced to compare CHARACTER values, as Assert:Equals may perform case-insensitive comparisons and ignores trailing whitespace.
2. Tests were added for cases referenced in #10471-6.

I've rebased 10471a to the latest trunk. The rev. is now 16355.

And -1 formatted with +hh:mm produces:

In OE: -00:01
In FWD (10471a): +00:-1

Special Number Formatting Specification¶

This document describes the legacy special time formatting applied to integer values
when the format string starts with one of the following exact prefixes:
hh:mm, hh:mm:ss, or +hh:mm
(with optional AM/PM suffix a or A in the literal suffix part).

This feature exists for backward compatibility (pre-OpenEdge 10).

Valid Format Specification¶

A format is recognized as a time format only if it starts with one of the following exact prefixes:

• hh:mm
• hh:mm:ss
• +hh:mm

followed by an optional literal suffix (any characters, including spaces, colons, letters, punctuation, etc.).

Important distinction for + prefix¶

• +hh:mm → recognized as cumulative signed time format (hours = total minutes % 60, sign preserved)
• +hh:mm:ss → not recognized as time format
  • The :ss part is treated as literal suffix
  • Example: STRING(1, "+hh:mm:ss") → +00:01:ss

Valid format rules:

• Placeholders h, m, s are case-insensitive
  • HH:MM:SS = hh:mm:ss = Hh:Mm:Ss = hH:mM:sS
• Minutes part must be exactly two placeholders (mm, MM, Mm, etc.)
• Seconds part must be exactly two placeholders (ss, SS, Ss, etc.) — only allowed in non-plus formats
• Single m or s (e.g. hh:m, hh:mm:s, hh:m:s) is invalid
• Incomplete patterns (e.g. h, hh, hh:, hh:m) are invalid
• Any characters after the recognized prefix (e.g. x in hh:mmx) are treated as literal suffix — not invalid
• AM/PM indicator (a or A) is optional and may appear anywhere in the suffix
• AM/PM indicator is case-sensitive for output:
  • A → uppercase A / P
  • a → lowercase a/ p
• Trailing spaces in the format string are not trimmed — they are copied literally to the output

If the format does not match one of the exact prefixes above, it is not considered a time format at all. Parsing continues as a standard numeric format, and any errors are raised according to normal numeric format validation rules (e.g. error 22 for invalid characters, error 148 for no digit placeholders).

Formatting Rules¶

Integer values (seconds since midnight) are formatted according to the following rules:

24-Hour vs 12-Hour Mode¶

• Without a/A: always 24-hour clock, hours padded with zero → 00:00:00 to 23:59:59 range.
• With a/A: 12-hour clock with AM/PM indicator

• Hour 0 → displayed as 12
• Hours 1–11 → displayed as-is (leading space if single digit in some cases)
• Hours 12 → displayed as 12
• Hours 13–23 → subtract 12, set PM

Midnight and Noon (value = 0 or 43200 seconds)¶

• 24-hour formats (no AM/PM): 00:00:00 / 00:00:00
• 12-hour formats (with a/A): 12:00:00 / 12:00:00 (AM for midnight, PM for noon)

Negative Values¶

• Non-plus formats (hh:mm, hh:mm:ss): count backward from midnight

• Equivalent to (value % 86400 + 86400) % 86400
• Examples:

• -1 → 23:59:59
• -60 → 23:59:00
• -20000 → 18:26:40

• Plus formats (+hh:mm): show negative cumulative time

• Absolute value used for calculation
• Original sign preserved
• "hh" field = total minutes % 60 (wraps every 60 hours)
• Examples:

• -1 → -00:01
• -60 → -01:00
• -200000 → -33:20

Large Values (> 86400 seconds)¶

• Non-plus formats: modulo 86400 seconds → time-of-day display

• Examples:

• 123456 → 10:17:36
• 1000001234 → 02:07:14

• Plus formats: no modulo on hours — cumulative display

• "hh" field still modulo 60
• Example:

• 1000001234 → +07:14

Suffix Handling¶

Any literal characters after the time prefix are preserved exactly, including trailing spaces.

• Trailing spaces in the format string are not trimmed — they are copied literally to the output
• This allows preserving alignment or padding in display fields
• AM/PM indicator may appear anywhere in the suffix

Examples:

• hh:mm:ss → 00:00:00 (3 trailing spaces preserved)
• +hh:mm → +00:00 (2 trailing spaces preserved)
• hh:mm:ssabc → 00:00:00abc (3 trailing spaces after literal suffix)
• hh:mm:ssxA → 13:02:03xP (AM/PM anywhere in suffix)
• +hh:mm:ss → +00:01:ss ( :ss is literal suffix)

Restrictions¶

• These formats are only valid for integer values
• Applying them to decimal values results in an error (e.g. error 22)
• They are not supported in FILL-IN widgets

Vladimir, do the attached test cases cover all the issues found?

10471a passed ChUI regression tests.

Hynek Cihlar wrote:

Vladimir, do the attached test cases cover all the issues found?

Yes, the latest version of TestIntegerFormattedAsTime.cls attached to this task contains all the formatting cases I can imagine.

Hynek Cihlar wrote:

10471a passed ChUI regression tests.

I rebased 10471a and re-tested with TestIntegerFormattedAsTime.cls. All tests passed.