Repository navigation
docker version JSON output uses mixed timestamp formats, seems to break downstream parsers (like VSCode DevContainers in remote configuration) #6727
Description
Description
When running:
docker version --format '{{json .}}'
the Docker CLI emits inconsistent timestamp formats for BuildTime fields within the same JSON document.
Observed on Docker Engine / CLI 28.5.1 (Linux, arm64).
Example (abridged):
• Client.BuildTime: "Wed Oct 8 12:18:19 2025" (human-readable)
• Server.BuildTime: "2025-10-08T12:18:19.000000000+00:00" (RFC3339 / ISO-8601)
• Server.Components[].Details.BuildTime: "Wed Oct 8 12:18:19 2025" (human-readable)
This mixed formatting seems to break consumers that reasonably assume a consistent, machine-readable schema when using --format {{json .}}.
⸻
Assumed impact on downstream tooling (please reproduce!)
In a VS Code Dev Containers setup using Remote-SSH (local VS Code client, Docker running on a remote Linux host), the Dev Containers extension invokes docker version --format {{json .}} during initialization.
Because of the inconsistent BuildTime formats, the extension crashes during JSON parsing with:
TypeError: Cannot read properties of undefined (reading 'toString')
It seems to me that this error breaks the extension, as it prevents opening or reopening a workspace in a dev container on the remote host, effectively blocking a common remote development workflow.
Reproduce
Run:
docker version --format '{{json .}}'
Inspect the JSON output, specifically the BuildTime fields:
• Client.BuildTime
• Server.BuildTime
• Server.Components[].Details.BuildTime
Expected behavior
All BuildTime fields in structured JSON output should use a single, consistent, machine-readable format (preferably RFC3339 / ISO-8601), or the schema should otherwise guarantee consistency.
docker version
Client: Docker Engine - Community
Version: 28.5.1
API version: 1.51
Go version: go1.24.8
Git commit: e180ab8
Built: Wed Oct 8 12:18:19 2025
OS/Arch: linux/arm64
Context: default
Server: Docker Engine - Community
Engine:
Version: 28.5.1
API version: 1.51 (minimum version 1.24)
Go version: go1.24.8
Git commit: f8215cc
Built: Wed Oct 8 12:18:19 2025
OS/Arch: linux/arm64
Experimental: false
containerd:
Version: v1.7.28
GitCommit: b98a3aace656320842a23f4a392a33f46af97866
runc:
Version: 1.3.0
GitCommit: v1.3.0-0-g4ca628d1
docker-init:
Version: 0.19.0
GitCommit: de40ad0docker info
Client: Docker Engine - Community
Version: 28.5.1
Context: default
Debug Mode: false
Plugins:
buildx: Docker Buildx (Docker Inc.)
Version: v0.29.1
Path: /usr/libexec/docker/cli-plugins/docker-buildx
compose: Docker Compose (Docker Inc.)
Version: v2.40.0
Path: /usr/libexec/docker/cli-plugins/docker-compose
Server:
Containers: 0
Running: 0
Paused: 0
Stopped: 0
Images: 0
Server Version: 28.5.1
Storage Driver: overlay2
Backing Filesystem: extfs
Supports d_type: true
Using metacopy: false
Native Overlay Diff: true
userxattr: false
Logging Driver: json-file
Cgroup Driver: systemd
Cgroup Version: 2
Plugins:
Volume: local
Network: bridge host ipvlan macvlan null overlay
Log: awslogs fluentd gcplogs gelf journald json-file local splunk syslog
CDI spec directories:
/etc/cdi
/var/run/cdi
Discovered Devices:
cdi: nvidia.com/gpu=0
cdi: nvidia.com/gpu=GPU-52fdf34c-87be-b467-706b-48e19f89711c
cdi: nvidia.com/gpu=all
Swarm: inactive
Runtimes: io.containerd.runc.v2 runc
Default Runtime: runc
Init Binary: docker-init
containerd version: b98a3aace656320842a23f4a392a33f46af97866
runc version: v1.3.0-0-g4ca628d1
init version: de40ad0
Security Options:
apparmor
seccomp
Profile: builtin
cgroupns
Kernel Version: 6.14.0-1015-nvidia
Operating System: Ubuntu 24.04.3 LTS
OSType: linux
Architecture: aarch64
CPUs: 20
Total Memory: 119.7GiB
Name: spark-bac8
ID: 70a78378-a286-494d-b0d4-f15e68268112
Docker Root Dir: /var/lib/docker
Debug Mode: false
Experimental: false
Insecure Registries:
::1/128
127.0.0.0/8
Live Restore Enabled: falseAdditional Info
I am a part-time developer, not a deep expert. If there is another reason for the failing of the VSCode DevContainers extension feature, happy if you point me to the right direction...
Activity
thaJeztah commentedon Jan 5, 2026
Related to / slightly duplicate of;
This is a slightly tricky one; ideally, the JSON output should indeed be consistent, but we need to look if changing the output in itself would be a breaking change. There was a slight change in v29, which was corrected in #6668, but checking output of a v23.0.4 setup, it looks like the output for some fields has always been "human readable";
Client.Buildtime:Fri Apr 14 10:32:04 2023Server.Components["Engine"].BuildTime:Fri Apr 14 10:32:04 2023Server.BuildTime:2023-04-14T10:32:04.000000000+00:00