Why Is My App Always in UTC? How to Set the Timezone in Your Kubernetes Pods

Have you ever finished deploying your shiny new app on Kubernetes - only to realize every log, timestamp, and scheduled event is stubbornly sticking to UTC? Let me tell you, there are few things as puzzling as watching your app run perfectly, but the logs tell what feels like the wrong time-travel story.

My first time encountering this was with a seemingly simple Node.js app. The app logic was sound, but my logs were off by hours, making troubleshooting a game of mental math. It took me a while to realize: by default, Kubernetes pods use UTC time, which is great for portability, but not always for real-world debugging. If you need your applications to keep local time or match your users’ timezone, you’ll need to tweak the pod configuration just a bit.

Why is UTC the Default?

The Kubernetes and container world adheres to UTC for predictability and global consistency. This avoids “works on my machine” problems, but shifts the burden onto you if your application, logs, or users rely on local time.

How to Set a Custom Timezone in Your Pod

While you can’t set the pod’s timezone directly via a single YAML field, there are straightforward ways to make your containers “think” in your desired timezone:

1. Set the TZ Environment Variable

Many Linux distributions (and several common base images) honor the TZ environment variable:

apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-app
    image: your-image:latest
    env:
    - name: TZ
      value: "Asia/Kolkata"   # Change to your timezone

This works easily with Debian/Ubuntu-based images and popular runtimes (Node.js, Python, PHP), but verify your base image supports TZ.

2. Mount the Host’s Localtime (For Advanced Cases)

For legacy apps or those relying on the system’s /etc/localtime and /etc/timezone files:

    volumeMounts:
        - name: tz-config
          mountPath: /etc/localtime
          readOnly: true
        - name: tz-data
          mountPath: /etc/timezone
          readOnly: true
    volumes:
      - name: tz-config
        hostPath:
          path: /usr/share/zoneinfo/Asia/Kolkata   # Your timezone
      - name: tz-data
        hostPath:
          path: /etc/timezone

Note: HostPath is less portable and is best for controlled environments.

3. Set Timezone in Your App Config

Some platforms or languages (like Java) need explicit flags in your app config or startup command:

command: ["java"]
args: ["-Duser.timezone=Asia/Kolkata", ...]

How to Find the Right TZ Value for Your Country or City

The value for TZ isn’t a guess—it follows the tz database (“IANA Time Zone”). The format is usually Region/City, and you must spell it exactly right.

Here’s how you can find the right value:

• Linux Command:
  Run timedatectl list-timezones on any Linux system to list all supported timezones.

• Online Reference:
  Search “IANA Time Zone database” or visit sources like Wikipedia for standardized entries.

• Examples:

  • America/New_York (Eastern US)

  • Europe/Berlin (Germany)

  • Asia/Kolkata (India)

  • Australia/Sydney (Australia Eastern)

• Tip:
  Avoid generic “CET”, “EST”, etc. Always use the Region/City format to avoid daylight saving confusion.

Quick Check

• Exec into your container and run date after deploying to verify.

• If your container doesn’t respond to TZ, check if it has tzdata installed and that it’s a full-featured Linux base image.

Final Thoughts

Configuring timezone in Kubernetes isn’t complicated, but it’s also not “automatic.” Next time you find yourself puzzled by UTC time on your logs, remember Kubernetes is doing exactly what it was told. With one of these methods, you can bring your pods back into your own timezone and stop guessing “what time was that error, really?”

Let me know if you’ve run into other timezone tricks or gotchas. I’d love to hear your stories!