Time Traveling Containers

All my projects start in the same manner, a cool little script, an idea or technology I want to work with or just something curious to me. The literal second I have something compiling I (or the AI Model of the week) would make a Dockerfile for it.

However, a while ago I was working with Google’s BuildPacks, a way to containerize applications for Google Services supporting Multiple languages. I pulled the latest version and …..

46 Years old….. Built 1980!? Its older than me!

Time traveling whales are not something I expected to see when I started working with containers, but here we are, this isn’t the first instance nor the last of this phenomenon.

The beginning of Unix Time

1970 is the first Unix Epoch, the time when the clock starts for Unix-based systems. So when you see a container image with a creation date of January 1, 1970, it could be due to a misconfiguration, default timestamp or in the case of some tools, a deliberate choice to set the creation time for reproducibility and consistency across builds.

1970 like Jib

Jib, is a popular Java containerization tool, sets the creation time of the image to 1970, for reproducibility reasons, as it allows for consistent builds regardless of when they are created.

10 Years later

For our buildpacks from Google, a company that wouldn’t be founded until 1998 - 19 years later - the reason 1980 is chosen is because this is the earliest date supported by ZIP files, which is the format used for the buildpacks. The ZIP file format - released 1989 - uses a timestamp that starts from January 1, 1980, so in order to be able to support the full range of dates, the creation time is set to this date.

How far back can we go?

Since we have seen 1970 and 1980, I wonder how far back we can go with these time traveling containers? The earliest date that can be represented in Unix time (Int32) is December 13, 1901, However, in practice, there should never be a reason to set a container’s creation date to anything that old…..

Unless I would want to send my Golang Gopher friend back to meet the Dinosaurs….

Sending Golang back to the Jurassic era

Golang is a very modern language that came out in 2009, great for cloud, microservices and containers, all things missing in the Jurassic era, but if I wanted to send my Gopher friend back to meet the Dinosaurs, I would just need to create a method to modify the Manifest Metadata of the container image to the earliest date possible.

Luckily I can create a Python Script to do this, build a modern golang webserver, containerize it and then modify the manifest to set the creation date to send my Gopher friend back to as far back as possible where he can meet the dinosaurs and live out his life before the creation of cloud.

We can go back to year 1 AD, which is the earliest date that can be represented in the timestamp. This would allow us to send our Gopher friend back to the 1st century of the AD Calendar, where he can meet historical figures.

Now our container is ….

292 Years old! We have failed 😭 Now he is stuck during the Industrial Revolution!

Why is 292.27 years the oldest date reported by Docker’s CLI?

Golang’s Time Date Int64

Golang is used for many containerization tools, and it uses a signed 64-bit integer counted in nanoseconds to represent time, which in normal use case and operation is more than sufficient for representing dates and times. However, when docker (or any other containerization engine) tries to compute the creation date or modified date of a container it does so by:

Max Age = (2^63 - 1) nanoseconds ÷ 1,000,000,000 ÷ 31,557,600 ≈ 292.27 years

Dividing the max int64 value by nanoseconds-per-second and then seconds-per-year gives ~292.27 years — so any timestamp further in the past than that causes an overflow, capping the oldest representable creation date at around 1733 (roughly 292 years before 2026).

Going Forward!

Lets create the oldest youngest container image possible, by setting the creation date to 9999 AD, which is the latest date that can be represented in the timestamp. Meaning anytime we type docker images --no-trunc we will see a container created "Less than a second ago" for the next 7,973 years!

This would allow us to make our Gopher friend immortal where he will live to the future where he will be a relic of the past, much like fortran and COBOL are today!

Conclusion

The Golang community may seek revenge for the situations and predicaments we have put our Gopher friend in, but I hope this article has shed some light on the phenomenon of time traveling containers and the reasons behind it.

Please feel free to pull the Github Repository or any of the built containers and have a play around with them, I did just build the Future Tag Release "Less than a second ago" so it is secure, maybe you can find a way to send our Gopher friend back to the Jurassic era or even further back to meet the dinosaurs!