Handling Expiration Format in Consul ACL Tokens
Consul does not provide a configuration option to interpret offset-less date-time strings as local or UTC time. The ACL token expiration parser strictly requires timestamps to follow the RFC3339/ISO8601 standard, which mandates an explicit timezone offset or a UTC indicator.
The Cause of the Error
The error parsing time "2026-10-11T19:13:28": invalid format occurs because the input string lacks a timezone designator. In Go-based applications like Consul, time parsing for these fields typically expects a format that includes the offset (e.g., Z for UTC or ±HH:mm for local offsets) to avoid ambiguity across distributed clusters.
Recommended Resolution
To resolve this, you must append a timezone offset to the expiration string. Depending on your requirements, use one of the following formats:
- UTC (Universal Coordinated Time): Append a
Z to the end of the string.
- Local Time with Offset: Append the offset from UTC (e.g.,
+05:30 or -08:00).
Example Commands:
# Using UTC (Recommended for distributed systems)
consul acl token create -expiration "2026-10-11T19:13:28Z"
# Using a specific local offset (e.g., UTC+5:30)
consul acl token create -expiration "2026-10-11T19:13:28+05:30"
Practical Verification
You can verify the strictness of the parser and the success of the fix by running these tests in your environment:
- Run
consul acl token create -expiration "2026-10-11T19:13:28" to confirm the "invalid format" error persists.
- Run
consul acl token create -expiration "2026-10-11T19:13:28Z" to confirm the token is created successfully.
- Verify your current version using
consul version to ensure you are on a supported release.
Assumptions and Limitations
This behavior is consistent with standard Consul stable releases. It is assumed that the user is interacting via the CLI or API. If you are using an external automation tool to generate these timestamps, you must configure that tool to output RFC3339 compliant strings rather than local date-time strings.
Diagnostic Detail: Are you generating these timestamps via a specific CI/CD pipeline or script? If so, the fix should be applied at the generation source to ensure all tokens are created with the required offset.
consul