Time zones: the pinned clock has no zone; CURRENT-DATE's UTC offset follows the process TZ; harness sides can run in different zones #3824

What: FUNCTION CURRENT-DATE positions 17–21 hold the UTC offset. With the date pinned, GnuCOBOL prints +0000 in the container but +0900 under TZ=Asia/Tokyo (probe): the offset follows the process time zone, not the pin.

• MainframeClock returns a LocalDateTime, with no zone.
• The JVM inherits the host's zone.
• Unpinned production uses the JVM's zone, not the mainframe's, so the business date rolls over at the wrong hour and daylight saving produces duplicate local times.

Where:

• cobol_to_java_batch_forge.py:398-399.
• equivalence_java.py (_clock, the environment) and equivalence.py:162.
• cobol_to_java_db2_forge.py:62: TIMESTAMP WITH TIME ZONE -> LocalDateTime drops the offset.

Test: Clock 2022/03/27 02:30:00.00 (a local time that doesn't exist in Europe/Berlin), DISPLAY FUNCTION CURRENT-DATE; the COBOL side runs under TZ=Europe/Berlin and the JVM under Asia/Kolkata. Expected: an identical 21-character value.

Fix:

• A zoned pin: gitgalaxy.clock plus gitgalaxy.zone, as ZonedDateTime / OffsetDateTime.
• The same TZ passed to Docker and the JVM.
• A configured "mainframe zone" in the generated application.

Found by a cultural-assumptions audit (2026-09-26): confirmed in code or by probe (JDK 17 locales, IBM code-page decoding, the harness's GnuCOBOL image) unless marked plausible.

🤖 Generated with Claude Code