litellm
litellm copied to clipboard
adds tzdata
🕰️ Make time zone configurable
Pre-Submission checklist
Please complete all items before asking a LiteLLM maintainer to review your PR
- [ ] ~~I have Added testing in the
tests/litellm/directory, Adding at least 1 test is a hard requirement - see details~~ - [ ] ~~I have added a screenshot of my new test passing locally~~
- [x] My PR passes all unit tests on
make test-unit - [x] My PR's scope is as isolated as possible, it only solves 1 specific problem
Type
🆕 New Feature
Changes
This PR adds tzdata as a runtime dependency to the Dockerfile. With tzdata installed, the environment variable TZ will be respected by Python's datetime module. This means that users can specify the timezone they want LiteLLM to use.
The latest updates on your projects. Learn more about Vercel for Git ↗︎
| Name | Status | Preview | Comments | Updated (UTC) |
|---|---|---|---|---|
| litellm | ✅ Ready (Inspect) | Visit Preview | 💬 Add feedback | May 13, 2025 0:55am |
Hey @Simon-Stone how does adding this to the dockerfile make the timezone configurable?
You can simply set the environment variable TZ for the container deployment to the desired time zone, e.g. TZ="America/New_York". Once this is set, Python's datetime module will use that time zone unless a different one is specified explicitly. So for example datetime.datetime.now() would be the local time New York, not UTC.
Got it. Can we have this as a pinned dependency on the requirements.txt instead? This would be easier for people to discover than in the dockerfile.
There is a python package called tzdata, but I am referring to the Linux package.
Would you still prefer this as a Python dependency?
if they're equivalent then sure, if not - i would defer to you on what you feel is best practice here
I think I'd prefer installing tzdata as a system package in the container.
The Python library is intended to be a fallback solution on systems that don't have tzdata already installed. According to PEP 615, it is best practice to install the system package alongside python whenever possible. So I would say including it at that level makes the most sense.
From my perspective, this PR should therefore be good to go.
So what do you think, @krrishdholakia ?
Looks good. Working on getting main stable. Then I'll merge this on a contributor branch for more complete testing.
If this isn't done by EOD - please bump me?
@krrishdholakia Sounds good. Thanks!