IBM i Date Format Converter

Why IBM i Dates Look Like 1260611

Most DB2/400 files predate the DATE data type, so dates live in plain numeric columns, and the shop standard that emerged from Y2K work is CYYMMDD: a century digit (0 for 19xx, 1 for 20xx), two-digit year, month, day. So 1260611 is June 11, 2026, and 0950611 is June 11, 1995. The layout sorts correctly as a number, packs tightly into a packed-decimal field, and survived the century rollover, which is why it is still everywhere: item files, transaction history, interface extracts. One wrinkle this tool handles automatically: a 19xx date stored in a numeric column loses its leading century zero on the way out, so 950611 in an extract is usually the same CYYMMDD field wearing six digits. If your dates arrive inside packed fields, decode them first with the Packed Decimal / COMP-3 Converter or map the whole record with the COBOL Copybook Explorer.

Julian Days, JDE, and the Two-Digit Window

The platform's other signature format is the day-of-year "Julian" date: YYDDD in job logs and older files, and CYYDDD with the century digit, which is exactly how JD Edwards World and EnterpriseOne store every date. 126162 is day 162 of 2026, June 11. These trip people up twice: day-of-year is not the astronomer's Julian day number, and a two-digit year means nothing without a windowing rule. RPG's date operations read two-digit years through a fixed 1940 to 2039 window, which this tool applies by default and lets you change, because an interface that assumes the wrong window silently shifts dates by a century. Retail date codes on case labels are a different animal again; for those, see the Date Code & Julian Date Decoder.

From One Column to a Clean Interface

The generated RPG, COBOL, and SQL exists because the real fix rarely happens in a browser: it happens in the program or query that reads the file. The SQL UDF variant packages the conversion once per library so every query can call it instead of repeating the arithmetic, and the RPG and COBOL snippets use the native date facilities (%date format codes, the date intrinsic functions) rather than string surgery. Date handling is where interface and migration projects quietly go wrong: a column that is CYYMMDD in one file, YYMMDD in another, and month-first in the spreadsheet a vendor sends. I build the extract, interface, and migration layers that keep date semantics intact end to end. See IBM i consulting, integration services, or modernization services.