Date and Timestamp Handling in YAML vs JSON

Date handling is a subtle but important difference between JSON and YAML. JSON has no native date type -- dates are always strings. YAML, however, can implicitly parse date-like values into date objects, which can cause unexpected behavior during conversion.

YAML implicit date parsing:

# These are automatically parsed as dates in YAML 1.1:
created: 2024-01-15
updated: 2024-01-15T10:30:00Z
time_only: 10:30:00

# These remain strings:
version: "2024.01"
not_a_date: "2024-01-15"

Converted to JSON (behavior depends on parser):

{
  "created": "2024-01-15T00:00:00.000Z",
  "updated": "2024-01-15T10:30:00Z",
  "time_only": 38400,
  "version": "2024.01",
  "not_a_date": "2024-01-15"
}

The problem: When you write created: 2024-01-15 in YAML, some parsers interpret this as a Date object, not a string. When serialized to JSON, it may become a full ISO 8601 timestamp or even a Unix timestamp, depending on the parser implementation.

Common date formats recognized by YAML 1.1:

• 2024-01-15 (date only)
• 2024-01-15T10:30:00Z (ISO 8601 with timezone)
• 2024-01-15 10:30:00 +09:00 (with offset)
• 2024-1-15 (without leading zeros)

YAML 1.2 removed implicit date type detection, but many popular parsers (PyYAML, js-yaml default mode) still use YAML 1.1 behavior.

Best practices for safe conversion:

1. Quote date strings in YAML if you want them to remain strings: created: "2024-01-15"
2. Use ISO 8601 format consistently when you do want dates: 2024-01-15T00:00:00Z
3. Be aware of your parser's YAML version. Test with actual date values to confirm behavior.
4. When converting JSON to YAML, date-like strings should be quoted to prevent unintended parsing.

The safest approach is to always quote date values in YAML unless you explicitly want date type parsing.