The TIME opcode retrieves the current system date and/or time into a result field. Factor 1 and Factor 2 are always blank:
C TIME result
The format of the result depends on the result field's type:
| Result Type | Format | Example |
|---|---|---|
| 6-digit numeric | HHMMSS (time only) | 181638 |
| 12-digit numeric | HHMMSS then a 6-place date, ordered by the job date format | 181638060126 (*MDY) |
| 14-digit numeric | HHMMSS then an 8-place date, ordered by the job date format | 18163806012026 (*MDY) |
| Date field (D) | Current date | 2026-06-01 |
| Time field (T) | Current time | 18.16.38 |
| Timestamp field (Z) | Current timestamp | 2026-06-01-18.16.38.127000 |
For numeric results the time portion (HHMMSS) always comes first, and the date
portion that follows is ordered by the job date format - the CHGJOB DATFMT /
QDATFMT value, not a control-spec DATFMT keyword and not the result field's own
type. *MDY is only the common default:
| Job date format | 12-place date portion | 14-place date portion |
|---|---|---|
*MDY (default) |
MMDDYY | MMDDCCYY |
*DMY |
DDMMYY | DDMMCCYY |
*YMD |
YYMMDD | CCYYMMDD |
*JUL |
YYDDD then a trailing zero | CCYYDDD then a trailing zero |
So a program that picks the date apart positionally gives different answers under different job formats - take the ordering from the job rather than assuming month first.
The result field must be one of the types above: a numeric field of exactly 6, 12, or 14 digits with zero decimal positions, or a Date, Time, or Timestamp field. A numeric field of any other length, a numeric field with decimal positions, or a non-numeric field (such as character) is rejected at compile time. The result width is never guessed.