How to bring back Docker image create time for Docker images list -- why do vendors always know better what changes customers need?
Daniel Nashed – 30 January 2026 18:46:16
I don't know why companies just decide which improvements are helpful for their customers and not providing a way to get back what was there before.
This looks like a trend. I don't see this just at Docker. But this is a good example.
Other examples is Apple with the new version 26. Some of the changes are really breaking the way users worked with their iPhone or iPad before.
The Facetime app is a good example, but also changes in the images app. Don't get me started.
When changing functionality users are used to, it could make sense to provide a setting to go back to the previous functionality.
In case of the "docker images" command there is no direct way to go back.
You can write your own script or alias with a more complex command line behind it.
I just added a new option to my dominoctl which I use with the alias "d" usually. So on my machines I can quickly list images in the way I want it.
The new default I set should be what you need in most cases and are a -- I would think -- practical output format, which should be OK for most admins.
But I also introduced a new dominoctl variable to specify your own format.
If not overwritten by CONTAINER_IMAGES_LIST_FORMAT the script uses the following command.
docker images --format "table {{.Repository}}\t{{.Tag}}\t{{.ID}}\t{{.Size}}\t{{.CreatedSince}}\t{{.Repository}}:{{.Tag}}"
Here is how the new output looks like. I am missing the created time date, which is often useful to see the age of the image.
Specially to spot newly created Domino container images.
docker images
IMAGE ID DISK USAGE CONTENT SIZE EXTRA
domino-nrpc-sni:latest 7110286a46c4 32.4MB 0B
grafana/grafana-enterprise:latest 7ddf287666f9 800MB 0B
hclcom/domino:14.5.1EA2 13568611b681 2.12GB 0B
hclcom/domino:14.5FP1 5f97041c031e 2.16GB 0B
hclcom/domino:latest 13568611b681 2.12GB 0B
mariadb:11 bfe9184ea9e5 334MB 0B
nashcom/dominodownload:latest 2e1568f167b3 92.8MB 0B
nginx:latest 60adc2e137e7 152MB 0B
prom/prometheus:latest 20a11eec2fec 378MB 0B
registry.access.redhat.com/ubi10:latest df13daf31556 212MB 0B
There is a --no-trunc option which gives you the full information including the full hash and the created time.
But mostly the full ID (SHA256) is almost never needed.
docker images --no-trunc
REPOSITORY TAG IMAGE ID CREATED SIZE
hclcom/domino 14.5.1EA2 sha256:13568611b68116590614675779b6e9489526cb1bd795da1f0052ac67e351c25c 25 minutes ago 2.12GB
hclcom/domino latest sha256:13568611b68116590614675779b6e9489526cb1bd795da1f0052ac67e351c25c 25 minutes ago 2.12GB
hclcom/domino 14.5FP1 sha256:5f97041c031e1b74dd12ce03ff8fc6635911b30693823428f2ea02cceabac5f2 49 minutes ago 2.16GB
mariadb 11 sha256:bfe9184ea9e5b839e6b01d279a2e508a3bb50e66c843dfd2183dd7608550ce78 2 weeks ago 334MB
nashcom/dominodownload latest sha256:2e1568f167b3b261a484aa233bdb725b7be63119c59a501f61cc2676cad31fad 3 weeks ago 92.8MB
grafana/grafana-enterprise latest sha256:7ddf287666f9a2a9bcfad24d1e916f2c5b3e967101e06063904086b2465b661e 6 weeks ago 800MB
registry.access.redhat.com/ubi10 latest sha256:df13daf315567aaa5c6e3045b9dc83cd99c670d64859eac902798d7a64187e75 6 weeks ago 212MB
prom/prometheus latest sha256:20a11eec2fec912184d2acaf1c3052ee163919feb3c8a0217fa6607b686b9b4c 6 weeks ago 378MB
nginx latest sha256:60adc2e137e757418d4d771822fa3b3f5d3b4ad58ef2385d200c9ee78375b6d5 2 months ago 152MB
domino-nrpc-sni latest sha256:7110286a46c4ec5d51b6ff40bc1d24a49755add3a5b59696b94d2c68d3cd8f80 3 months ago 32.4MB
Here is the format I came up with.
It shows the size before the created and also shows the repository:tag. That's often useful for copy and paste.
dominoctl images
REPOSITORY TAG IMAGE ID SIZE CREATED REPOSITORY:TAG
hclcom/domino 14.5.1EA2 13568611b681 2.12GB 26 minutes ago hclcom/domino:14.5.1EA2
hclcom/domino latest 13568611b681 2.12GB 26 minutes ago hclcom/domino:latest
hclcom/domino 14.5FP1 5f97041c031e 2.16GB 50 minutes ago hclcom/domino:14.5FP1
mariadb 11 bfe9184ea9e5 334MB 2 weeks ago mariadb:11
nashcom/dominodownload latest 2e1568f167b3 92.8MB 3 weeks ago nashcom/dominodownload:latest
grafana/grafana-enterprise latest 7ddf287666f9 800MB 6 weeks ago grafana/grafana-enterprise:latest
registry.access.redhat.com/ubi10 latest df13daf31556 212MB 6 weeks ago registry.access.redhat.com/ubi10:latest
prom/prometheus latest 20a11eec2fec 378MB 6 weeks ago prom/prometheus:latest
nginx latest 60adc2e137e7 152MB 2 months ago nginx:latest
domino-nrpc-sni latest 7110286a46c4 32.4MB 3 months ago domino-nrpc-sni:latest
In this case it was easy to address. And now there is more flexibility and choice.
I would wish vendors would take more care when changing functionality. and offer choices when they are not sure if the changed behavior is good for everyone.
Also they could ask their community. Like Docker Captains and HCL Ambassadors for example before updating something customers might rely on.
- Comments [0]
![[HCL Domino]](../lotus-domino.gif){kind=small}
![[Domino on Linux]](../domino-linux.gif){kind=small}
![[Nash!Com]](../nashcom.gif){kind=small}
![[Daniel Nashed]](../daniel-nsh.gif){kind=small}