
K8s Timezone Config
- 88 installs
- 6 repo stars
- Updated July 22, 2026
- julianobarbosa/claude-code-skills
Helps with ai & agent building tasks.
About
k8s-timezone-config is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted development.
- k8s-timezone-config
- AI & Agent Building
- AI-coding skill
K8s Timezone Config by the numbers
- 88 all-time installs (skills.sh)
- +1 installs in the week ending Aug 2, 2026 (Skillselion tracking)
- Ranked #4,902 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
- Data as of Aug 3, 2026 (Skillselion catalog sync)
npx skills add https://github.com/julianobarbosa/claude-code-skills --skill k8s-timezone-configAdd your badge
Show developers this skill is listed on Skillselion. Paste this into your README.
| Installs | 88 |
|---|---|
| repo stars | ★ 6 |
| Last updated | July 22, 2026 |
| Repository | julianobarbosa/claude-code-skills ↗ |
What it does
Helps with ai & agent building tasks.
Files
Kubernetes Pod Timezone Configuration
Standard timezone for Hypera infrastructure: America/Sao_Paulo
Problem
Kubernetes pods run in UTC by default. Logs and application timestamps show +0000 offset instead of local Brazil time (-0300).
Solution
Add the TZ environment variable to container specifications.
Implementation Patterns
1. Helm Values (extraEnv pattern)
For Helm charts that support extraEnv:
# In values.yaml
extraEnv:
- name: TZ
value: America/Sao_Paulo2. Multiple Containers
When a deployment has multiple containers (e.g., API server + frontend), add TZ to ALL containers:
apiServer:
extraEnv:
- name: TZ
value: America/Sao_Paulo
frontend:
extraEnv:
- name: TZ
value: America/Sao_Paulo3. Raw Kubernetes Deployment
apiVersion: apps/v1
kind: Deployment
spec:
template:
spec:
containers:
- name: app
env:
- name: TZ
value: America/Sao_Paulo4. StatefulSet
apiVersion: apps/v1
kind: StatefulSet
spec:
template:
spec:
containers:
- name: app
env:
- name: TZ
value: America/Sao_PauloVerification
After deployment, verify timezone is set correctly:
# Check pod logs for timestamp offset
# Before: 2026-01-13T11:37:06 +0000
# After: 2026-01-13T08:37:06 -0300
# Or exec into pod
kubectl exec -it <pod-name> -n <namespace> -- date
# Should show: Mon Jan 13 08:37:06 -03 2026Common Applications Requiring Timezone
| Application | Config Location | Notes |
|---|---|---|
| Dependency-Track | apiServer.extraEnv + frontend.extraEnv | Both containers need TZ |
| Grafana | env or extraEnvVars | Single container |
| Loki | extraEnv | Affects log timestamps |
| Prometheus | server.env | Affects alert timestamps |
| DefectDojo | extraEnv | Django app |
| PostgreSQL | primary.extraEnvVars | Database timestamps |
Important Notes
1. Restart required: Pods must restart for TZ changes to take effect 2. All containers: Set TZ on ALL containers in a pod, including sidecars 3. Init containers: Also set TZ on init containers if they log timestamps 4. Cron jobs: Kubernetes CronJob schedules are always UTC - TZ only affects container-level time
Hypera GitOps Workflow
1. Edit values.yaml in argo-cd-helm-values/kube-addons/<service>/<cluster>/values.yaml 2. Add TZ environment variable to all containers 3. Commit and push (ArgoCD auto-syncs) 4. Verify pods restart with new timezone
Reference
- IANA Timezone Database:
America/Sao_Paulo= UTC-3 (no DST since 2019) - Linux TZ variable: Uses
/usr/share/zoneinfo/America/Sao_Paulo
---
Gotchas
- `TZ` env var only affects app-level timestamps, not
kubectl logstimestamps (those come from the container runtime, which stays UTC). The kubelet timestamps stay+0000even after the pod's internal clock is São Paulo. - CronJob `schedule:` is always UTC regardless of pod
TZ. A0 8 * * *schedule fires at 05:00 BRT, not 08:00 BRT. Usespec.timeZone: America/Sao_Pauloon the CronJob itself (K8s 1.27+) or compute the UTC offset manually. - Distroless and scratch images have no `/usr/share/zoneinfo` —
TZ=America/Sao_Paulosilently falls back to UTC. Either use a base image that ships tzdata or mount it via configMap/volume. - Init containers don't inherit `TZ` from the main container in older charts — set it on the init container spec separately or their migration logs stay UTC.
- Java apps need `-Duser.timezone=America/Sao_Paulo` in JAVA_OPTS in addition to TZ — the JVM reads its own property, not the env var, on some distributions.
- PostgreSQL `TZ` env var sets the OS clock, not the database
timezonesetting. Server timestamps vianow()still use the value inpostgresql.conf— set both.