Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Standardized Timezone Configuration for Coder Deployment and User Interfaces#15519

matifali started this conversation inRFCs
Discussion options

Summary

This RFC proposes a standardized approach to managing timezone configurations across Coder deployments, including database interactions and user interfaces. The objective is to ensure a consistent timezone configuration that supports deployment-level and user-level needs without reliance on environment-specific settings that may vary across replicas and clusters.

Background

Currently, there is no deployment-wide or user-wide timezone configuration in Coder. Timestamps are typically stored in UTC, yet displayed timezones can differ across environments and users, resulting in inconsistent data views, particularly in metrics and insights. One example is the DAU graph, which gets different results based on the timezone of the user viewing it.

Goals

  • Consistent Deployment-wide Timezone: Ensure all Coder components operate with a unified timezone setting.
  • User-Level Timezone Settings: Allow user-configured timezone settings for personalized views, especially in UI elements.
  • Clear Database Handling: Store all timestamps in UTC and adjust timezones only when displaying data to the user.
  • UI Transparency: Enable configuration of timezone settings within the Coder UI to improve visibility and manageability.

Proposed Solution

1. Database Timezone Consistency

  • Timestamp Storage: Store all timestamps in PostgreSQL astimestamptz in UTC.
  • Timestamp Retrieval: Retrieve timestamps from the database in UTC and convert to the appropriate timezone only when displaying data.

2. Deployment-Level Timezone Configuration

  • Definition: Define a deployment-wide timezone that applies uniformly across the Coder environment for consistency in insights, metrics, and system-level timestamps.
  • Implementation:
    • Environment Variable (TZ): Continue allowing theTZ environment variable to set the initial deployment timezone, but enable a dedicated configuration within the Coder UI for transparency.
    • Fallback Behavior: Default to UTC if the configured timezone is invalid or cannot be retrieved.

3. User-Level Timezone Settings

  • Purpose: Allow users to select a timezone for personalized adjustments, which will be reflected in:
    • Autostart and Autostop schedules
    • UI and CLI timestamp displays
  • Configuration Location: Add a timezone setting within user account settings, enabling each user to select their preferred timezone.

4. Display Handling

  • Insights and Metrics: Default to the deployment-level timezone for aggregated metrics and data visualizations (e.g., DAUs), ensuring a unified view for all users.
  • User-Specific Data: Adjust based on the user's account-level timezone for individual settings (like autostart/stop times).

5. UI Configuration and Management

  • Deployment Settings UI: Expose the deployment-wide timezone setting in the Coder UI, allowing administrators to view and adjust the timezone without relying solely on theTZ environment variable.
  • User Account Settings UI: Include a timezone configuration option in user account settings, ensuring user-level timezone preferences are respected across all UI and CLI displays.

Open Questions

  • Should the deployment-wide timezone be configurable at the organization level or a global setting across the deployment?
  • What fallback should be implemented if neither theTZ environment variable nor the UI configuration is available or valid?
  • Is there a value in providing a user-levelTZ setting?
You must be logged in to vote

Replies: 2 comments 1 reply

This comment has been hidden.

@matifali

This comment has been hidden.

Comment options

I'm strongly against the idea of a "deployment" timezone. It's extra config and an extra choice the admins have to make with no clear benefit.

We already support computing the DAUs in arbitrary time zones (to 30min increments), and the most sensible default is the time zone of the person viewing the graph. We can add GUI options to compute plots in an explicitly chosen timezone, a la Grafana, Datadog, etc. in future if it becomes a highly requested feature for admins to be able to reproduce exactly the same plots.

When it comes to displaying daily user totals by created_at --- this data is unambiguous in terms of the actual moment in time it represents, so again, we should be able to query daily totals in an arbitrary time zone, and on the UI should default to the viewer's time zone.

Timestamps, when listed in things like logs, shouldalways be in UTC.

You must be logged in to vote
0 replies
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
RFCs
Labels
None yet
2 participants
@matifali@spikecurtis

[8]ページ先頭

©2009-2025 Movatter.jp