Conversation
Import time/tzdata so time.LoadLocation and the TZ environment variable resolve on the bare Alpine runtime image, which ships no tzdata package. Unset TZ still means UTC. Adds ~450KB to the binary.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review. 📝 WalkthroughWalkthroughThe API binary now embeds the IANA timezone database. The environment example documents the optional ChangesTimezone support
Priority: ➖ Normal Estimated code review effort: 1 (Trivial) | ~5 minutes Change: Bug fix · Severity of issue fixed: Medium Suggested reviewers: Merge Risk: ⚪ Minimal · up to The API can use configured IANA time zones for log timestamps in the Alpine runtime while retaining UTC when TZ is unset. No actionable merge risk remains. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
time/tzdataincmd/api/main.gosotime.LoadLocationand theTZenvironment variable resolve on the runtime image, which is Alpine-based and ships notzdatapackage.TZhas no effect and log timestamps are stuck in UTC regardless of what the operator sets.TZstill means UTC, same as before.TZin.env.example.Fixes #48
Test plan
go build ./...succeedsTZ=Pacific/Aucklandset and confirmed log timestamps reflect the local offset instead of UTCSummary by CodeRabbit
New Features
TZenvironment variable.Documentation
TZsetting and supported timezone format in the environment configuration example.