Fixing Docker Compose Images Incorrect CREATED Date Display Bug

Hey guys! Ever run into a weird issue where Docker Compose shows a wildly inaccurate creation date for your images? Like, 292 years ago? Yeah, it’s a head-scratcher, but don't worry, we're going to break down this bug, why it happens, and how it affects you. Let’s dive in!

Understanding the Docker Compose Images CREATED Date Bug

So, you're using Docker Compose images, and instead of seeing a reasonable date, you’re greeted with “292 years ago.” This incorrect CREATED date isn't just a visual glitch; it can mess with your understanding of when your images were actually built or pulled. This issue arises because Docker Compose, specifically, the docker compose images command, is pulling the wrong timestamp. Instead of using the image's actual build or creation time, it’s looking at the LastTagTime field in the image metadata. When an image is pulled or built without a local tag event, this LastTagTime defaults to 0001-01-01T00:00:00Z, hence the 292-year discrepancy. The underlying image configuration does have a valid .Created field, which holds the correct timestamp, but this field is being ignored by the docker compose images command. This is super frustrating because you’re not getting an accurate view of your images’ history, which is crucial for debugging and maintaining your Dockerized applications. The core issue lies in how Docker Compose is designed to display image creation times. It's designed to show the time of the last tag, which, if never set, defaults to an extremely early date. This can lead to significant confusion, especially when you're trying to track down when an image was built or updated. For instance, if you're trying to roll back to a previous version of an image and rely on the CREATED column to identify the correct one, you'll be misled by this incorrect date. To make matters worse, this incorrect date can affect scripting and automation tools that rely on parsing the output of docker compose images. If your scripts are expecting a reasonable date and encounter “292 years ago,” they may fail or produce unexpected results. This is a serious problem for continuous integration and continuous deployment (CI/CD) pipelines, where accurate image tracking is essential. Understanding this bug is the first step in working around it. Knowing that the issue stems from the LastTagTime field, you can start to look for alternative ways to retrieve the correct creation time, such as using docker inspect or other Docker commands that access the .Created field directly. The key takeaway here is that the docker compose images command, in its current state, is not a reliable source for image creation times. You need to be aware of this limitation and use other methods to get the accurate information you need.

Expected vs. Actual Behavior: What Went Wrong?

Ideally, when you run docker compose, the images command should display the actual build or creation time of your images. This makes perfect sense, right? You want to know when an image was made to help manage and maintain your containers. The expected behavior is that the CREATED column would show a recent, relevant timestamp, something that matches when you built the image or pulled it from a registry. This helps you track versions, troubleshoot issues, and generally keep your Docker environment organized. However, the actual behavior is far from this ideal. Instead of showing the real creation time, docker compose images displays “292 years ago” for many images. This is because it's mistakenly rendering the Metadata.LastTagTime field, which, as we discussed, defaults to a very old date if not explicitly set. This means the tool is showing a completely misleading date, making it hard to understand the age and origin of your images. Think about it: you pull an image today, but the command tells you it was created centuries ago. That's not just confusing; it's actively unhelpful. The discrepancy between expected and actual behavior can lead to several practical problems. For example, if you're trying to identify the most recent version of an image, you might accidentally pick an older one because the CREATED column suggests it’s ancient. This can lead to deployment errors, security vulnerabilities, and a general lack of confidence in your container management process. Moreover, this issue can complicate debugging efforts. When something goes wrong, you often need to know the exact versions of the images you're using. If the creation dates are incorrect, it becomes much harder to pinpoint the source of the problem. Imagine you're rolling out a new feature and something breaks. You want to know if the issue is in the latest image or if it's a problem that existed in previous versions. With the wrong dates, you're essentially flying blind. The root cause of this mismatch lies in the code of Docker Compose itself. As identified in the bug report, the images.go file in the Compose codebase is set to use i.LastTagTime instead of i.Created. This seems like a simple oversight, but it has significant implications for usability and reliability. The developers likely intended to show when an image was last tagged, but this approach fails when the image hasn't been tagged locally or when the tag time hasn't been properly recorded. To sum it up, the expected behavior of docker compose images is to provide accurate creation timestamps, but the actual behavior is to display a default, nonsensical date due to a coding error. This discrepancy not only confuses users but also hinders effective container management and troubleshooting.

Reproducing the Bug: Step-by-Step

Want to see this Docker Compose images bug in action? It’s surprisingly easy to reproduce. This means you can test it out yourself and verify that you’re encountering the same issue. Let's walk through the steps. First, you need to create a new directory for your Docker Compose project. This keeps things tidy and ensures you’re working in a clean environment. Open your terminal and run:

mkdir dockertest && cd dockertest

Next, you'll need a docker-compose.yaml file. This file defines your services, networks, and volumes, essentially orchestrating your Docker containers. Create a new file named docker-compose.yaml in your dockertest directory and paste in the following minimal configuration for an Alpine Linux image:

services:
 alpine:
 image: alpine:3.18
 command: sleep 3600

This configuration sets up a single service named alpine that uses the alpine:3.18 image. The command: sleep 3600 ensures the container stays running for an hour, giving you time to inspect it. Now, it’s time to bring your service up using Docker Compose. Run the following command in your terminal:

docker compose up -d

The -d flag runs the containers in detached mode, meaning they’ll run in the background. Docker Compose will pull the Alpine image if it’s not already present on your system and start the container. Once the service is up and running, you can check the image creation date using the command that triggers the bug:

docker compose images

You should see output similar to this:

CONTAINER REPOSITORY TAG PLATFORM IMAGE ID SIZE CREATED
dockertest-alpine-1 alpine 3.18 linux/amd64 802c91d52981 7.36MB 292 years ago

Notice the CREATED column? It says “292 years ago,” even though you just pulled the image. This confirms that the bug is present. To further verify the issue, you can inspect the image directly using docker inspect. This command provides detailed information about a Docker object, including the actual creation time. Run the following command:

docker inspect alpine:3.18 | grep -i created

The output will show the correct creation timestamp, something like:

 "Created": "2025-02-14T03:03:06Z",

This clearly contrasts with the “292 years ago” displayed by docker compose images. You can also check the LastTagTime field directly using:

docker inspect --format '{{json .Metadata}}' alpine:3.18

This will output:

{"LastTagTime":"0001-01-01T00:00:00Z"}

Confirming that LastTagTime is the source of the incorrect date. By following these steps, you've successfully reproduced the bug and seen firsthand how Docker Compose is displaying the wrong image creation date. This understanding is crucial for identifying workarounds and advocating for a fix.

Diving into the Cause: The LastTagTime Culprit

So, we've seen the problem – incorrect CREATED dates in docker compose images. We've reproduced it, but why is this happening? The culprit is a specific field in the image metadata: LastTagTime. As we've mentioned, Docker Compose mistakenly uses this field to populate the CREATED column, leading to the