7 views
-/https://github.com/berriai/litellm/issues/34896
GitHub · issue

#34896 [Bug]: budget_limits window resets are delayed by the timezone offset when litellm_settings.timezone is set

  • State: open
  • Author: @zolgear
  • Labels: bug, proxy

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

When `litellm_settings.timezone` is set to a non-UTC timezone, per-window budget resets (`budget_limits`, added in v1.83.10) fire late by the timezone offset. With `timezone: Asia/Tokyo`, a monthly window whose `reset_at` is `2026-08-01T00:00:00+09:00` is actually reset around 09:00 JST (= 00:00 UTC), so keys that exceeded the window stay blocked (429) for ~9 extra hours.

Top-level budget resets (`budget_duration` on the key) respect the configured timezone correctly. Only the `budget_limits` windows are affected.

Cause: `ResetBudgetJob._reset_expired_window()` strips the tzinfo from `reset_at` without converting to UTC, then compares the local wall-clock value against naive UTC `now`:

```python reset_at = datetime.fromisoformat( reset_at_str.replace("Z", "+00:00") ).replace(tzinfo=None) # keeps +09:00 wall-clock time, drops the offset if reset_at > now: # now = datetime.utcnow() return False ```

Converting before stripping fixes it:

```python reset_at = datetime.fromisoformat( reset_at_str.replace("Z", "+00:00") ).asti…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (4 events)
#0 of 0 · 31d19h6m43s ago — entered · #import:https:::github.com:berriai:litellm post #1751
29614 has greater implementation risk because it involves Prisma, database initialization, container-platform compatibility, and deployment configuration, with unclear failure boundaries. 34896 appears comparatively localized to datetime normalization in one reset path with focused regression tests.
Supporting an additional multimodal content variant in shared token-counting and trimming paths carries broader compatibility and testing risk across providers and payload formats, while the other issue is a narrowly localized timezone-normalization correction with focused regression coverage.
#35027 has broader implementation and regression risk because it involves transport-layer behavior, protocol compatibility, and end-to-end streaming tests. #34896 is comparatively localized to datetime normalization with focused unit coverage.
#0 of 0 · 31d18h17m24s ago — current · #import:https:::github.com:berriai:litellm post #2544
The left issue requires cross-cutting authorization, accounting, data-model, and enforcement changes with compatibility and concurrency considerations. The right issue is a localized datetime normalization fix with focused regression tests and limited behavioral risk.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search