YAML

YAML does have a timestamp type — and it will coerce your strings when you least expect it.

Unlike JSON, YAML 1.1 defines a built-in timestamp type. A bare scalar like 2026-06-05 or 2026-06-05T14:00:00Z in a YAML 1.1 document may be parsed into a native date or datetime object by the library — without any explicit type tag. The same auto-coercion applies to values like yes, no, on, off, and true/false in the boolean type. If your application expected a string and got a datetime object, behaviour depends entirely on how that object is subsequently serialised or compared.

To keep a value as a string, quote it: "2026-06-05" or '2026-06-05'. A quoted scalar is always a string in YAML, regardless of its content.

YAML 1.2 revised the core schema to reduce implicit coercions — notably, yes/no/on/off are strings in the 1.2 core schema, not booleans, and timestamp coercion depends on which schema the parser uses. Real-world behaviour still varies significantly by library and version: PyYAML defaults to 1.1 semantics, ruamel.yaml supports both, Go’s gopkg.in/yaml.v3 follows 1.2 more closely. Always check your library’s version and default schema.

The Norway problem and dates

The “Norway problem” originally referred to the country code NO being parsed as boolean false under YAML 1.1 boolean rules. The same category of surprise applies to dates: the bare value 2015-01-01 is a perfectly valid ISO 8601 date string in your intent, but a YAML 1.1 parser may hand your application a datetime object. Downstream code that does if value == "2015-01-01" will never match.

Pitfall: Writing an unquoted date scalar in a YAML config file (e.g. default_date: 2026-06-05) and assuming it stays a string. If the YAML library is running in 1.1 mode, the value arrives in application code as a native date object. Code that expects a string — for logging, comparison, or re-serialisation — will silently produce wrong output or raise a type error.

Go deeper: schema differences across YAML versions and libraries

YAML 1.2 defines three built-in schemas with progressively more coercions:

Failsafe schema: only strings, mappings, and sequences — no implicit coercions at all.
JSON schema: bool, int, float, and null coercions that match JSON semantics; no timestamp type.
Core schema: superset of JSON schema; still no timestamp type in the 1.2 core schema.

The timestamp type in common use comes from the YAML 1.1 spec (and its informal successor, the “YAML type repository”). Libraries that default to 1.1 semantics or that implement a “full” schema on top of 1.2 will coerce date-like strings. The safest cross-library approach is to quote all date and time values in your YAML files and explicitly parse them in application code with the format you expect.

If you own the YAML-producing side (e.g. generating config files programmatically), emit quoted date strings unconditionally. If you consume third-party YAML, treat any value that “should be a date” as potentially already a native date object in your parsing layer, and handle both types defensively.