1Overview

The LocalDateTime scalar type represents a date and time without time zone information. It is intended for scenarios where time zone context is either unnecessary or managed separately, such as recording birthdates and times (where the event occurred in a specific local context), displaying timestamps in a user’s local time zone (where the time zone is known from context), or recording historical timestamps where the time zone was not captured.

Unlike instant-based DateTime scalars that represent a specific moment in time, LocalDateTime represents a calendar date and wall-clock time that could refer to different moments depending on the time zone context applied to it. This makes it suitable for applications where the time zone is managed separately from the date-time value itself.

The scalar uses RFC 3339 format for serialization, specifically the full-date and partial-time productions combined with a T or t separator, but without time zone offset information.

2Recommended name

The recommended name for this scalar is LocalDateTime.

3Result spec

A LocalDateTime scalar must serialize to a string conforming to the RFC 3339 full-date and partial-time productions combined with a T or t separator, but without the time-offset component. This represents a local date and time in the format: YYYY-MM-DDTHH:mm:ss or YYYY-MM-DDTHH:mm:ss.fffffffff (with optional fractional seconds).

The format is:

• YYYY: Four-digit year
• MM: Two-digit month (01-12)
• DD: Two-digit day (01-31, valid for the given month)
• T or t: Literal separator character
• HH: Two-digit hour (00-23)
• mm: Two-digit minute (00-59)
• ss: Two-digit second (00-59)
• .fffffffff: Optional fractional seconds (up to 9 digits for nanosecond precision)

The serialized value must not include time zone offset information (e.g., Z, +00:00, or -05:00) as specified in the RFC 3339 time-offset production.

4Input spec

A LocalDateTime scalar accepts string values conforming to the RFC 3339 full-date and partial-time productions combined with a T or t separator, but without the time-offset component, both as GraphQL literals and as JSON input values.

The input format matches the result format and must:

• Follow the pattern YYYY-MM-DDTHH:mm:ss or YYYY-MM-DDTHH:mm:ss.fffffffff
• Not include time zone offset information (Z or +/-HH:mm)
• Contain valid date and time values per RFC 3339
• Use either uppercase T or lowercase t as the separator between date and time components

Implementations should validate:

• Year is a valid four-digit number
• Month is between 01 and 12
• Day is valid for the given month and year (accounting for leap years)
• Hour is between 00 and 23
• Minute is between 00 and 59
• Second is between 00 and 59 (leap seconds are not supported)
• Fractional seconds, if present, are numeric (up to 9 digits)

mutation {
  updateProfile(birthDateTime: "2023-12-24T15:30:00") {
    id
  }
}

{
  "birthDateTime": "2023-12-24T15:30:00"
}

{
  "birthDateTime": "2023-12-24t15:30:00.123456789"
}

5References

• RFC 3339 — Date and Time on the Internet: Timestamps