8 views
-/https://github.com/berriai/litellm/issues/31831
GitHub · issue

#31831 [Feature]: Configurable reporting timezone for usage and spend

  • State: open
  • Author: @limitjupyter-ops
  • Labels: enhancement, proxy

### Check for existing issues

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

### The Feature

I would like LiteLLM to support a configurable reporting timezone for usage, spend logs, exports, and Admin UI display.

Suggested behavior:

1. Admins can configure a global reporting timezone. 2. Usage and spend date filters use the configured timezone for business-day boundaries. 3. CSV/export timestamps can be formatted in the configured timezone. 4. Admin UI displays usage/spend times consistently. 5. Optional future support for org/team/user-level timezone defaults.

Example:

```yaml general_settings: reporting_timezone: Asia/Shanghai

### Motivation, pitch

Many companies operate usage and finance reporting by a fixed business timezone rather than UTC or the browser timezone.

For example, a company may define monthly usage, daily reports, and billing exports using `Asia/Shanghai`. If backend aggregation uses UTC while UI or exports use local time, totals can appear inconsistent around day/month boundaries.

A configurable reporting timezone would make LiteLLM usage and spend reports easier to reconcile with internal business reporting. …

GitHub resolver

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

Refresh page
vote history (8 events)
#0 of 0 · 31d19h28m59s ago — entered · #import:https:::github.com:berriai:litellm post #1710
Issue 31831 spans cross-cutting configuration, date-boundary semantics, persistence/aggregation behavior, exports, and UI consistency, creating substantially broader integration and regression risk. Issue 27113 appears localized to a model-specific request-processing path with focused tests and limited surface area.
The right item has broader cross-layer scope, requiring coordinated configuration, persistence/query semantics, formatting, UI behavior, and edge-case validation. The left is comparatively localized to protocol-aware request translation with focused compatibility tests.
Configurable timezone support is harder because it spans backend aggregation, date-boundary semantics, exports, UI formatting, configuration validation, and timezone/DST compatibility. The provider addition is more contained around an audio adapter, request handling, and provider-specific tests.
The right issue is harder because it spans configuration, timezone-aware aggregation and filtering, export formatting, and coordinated Admin UI behavior across multiple layers. The left issue is comparatively localized to response normalization and regression coverage in embedding handlers.
The right-hand change is a broad cross-layer feature involving configuration, date-boundary calculations, reporting queries, exports, UI consistency, timezone edge cases, and backward compatibility. The left-hand work is more likely a localized provider-behavior investigation and configuration or documentation fix.
Issue #31831 is harder because it requires cross-cutting configuration design, timezone-aware aggregation and boundary handling, propagation across backend APIs, exports, and UI, plus migration, compatibility, and extensive consistency testing. Issue #26784 is comparatively localized to correcting a streaming response model/serialization mismatch and validating provider-specific regression behavior.
A new gateway integration carries greater protocol, authentication, routing, translation, compatibility, testing, and operational risk, while timezone support is largely a bounded cross-layer reporting and presentation change.
#0 of 0 · 31d18h24m57s ago — current · #import:https:::github.com:berriai:litellm post #2754
The right issue spans configuration, timezone-aware aggregation and filtering, exports, and UI consistency, creating broader cross-layer changes and edge-case risk. The left issue is comparatively localized to stream block serialization with targeted compatibility tests.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search