2026-09-30 · 5 min read · Rahul Chitturi
- yaml
- config
- dates
YAML 1.1 resolves an unquoted value such as 2026-09-30 into a timestamp. The application then formats that timestamp back to a string and can shift the calendar day. A date-only midnight in one zone is the previous evening in another.
Quoted '2026-09-30' stays a string. YAML 1.2 JSON schema also leaves that token as text. The bug appears when a library still uses YAML 1.1 timestamp resolution and a later JSON step prints a full date-time.
Capture the token before and after parsing
Save the raw YAML line, the parser name and version, and the value after load. A timestamp object, a string, and a JSON date-time are three different results. Also record the process time zone, because formatting often uses local time.
- Quote calendar dates that must stay strings.
- Pin the YAML schema or loader version.
- Compare date-only input with the emitted instant.
- Keep version numbers such as 1.10 quoted too.
Find which hop changed the type
Helm, Kubernetes client libraries, and application config loaders do not share one YAML version. A value can remain a string through CI and become a timestamp only in the service binary.
If the stored instant is midnight UTC, a formatter west of UTC prints the previous date. The file did not contain that previous date. The conversion invented a time of day and then displayed it in another zone.
Diff the loaded JSON before deploy
Use Flashman's YAML/JSON converter to see the loaded value, the JSON formatter to inspect the emitted document, diff to compare it with the quoted source, and the timestamp converter to place midnight in the service time zone.
Test a date-only value, a date-time with Z, a quoted date, and the same file in the CI loader and the production loader. Ship the config when both loaders still show the calendar day you wrote.