Standardized Timezone Configuration for Coder Deployment and User Interfaces #15519

matifali · 2024-11-14T15:39:36Z

matifali
Nov 14, 2024
Maintainer

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 as timestamptz 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 the TZ 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 the TZ 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 the TZ environment variable nor the UI configuration is available or valid?
Is there a value in providing a user-level TZ setting?

spikecurtis · 2024-11-19T16:55:42Z

spikecurtis
Nov 19, 2024
Collaborator

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, should always be in UTC.

0 replies

This comment has been hidden.

Sign in to view

This comment has been hidden.

Sign in to view

This comment has been hidden.

Sign in to view

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Standardized Timezone Configuration for Coder Deployment and User Interfaces #15519

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 2 comments 1 reply

This comment has been hidden.

This comment has been hidden.

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Standardized Timezone Configuration for Coder Deployment and User Interfaces #15519

Uh oh!

Uh oh!

matifali Nov 14, 2024 Maintainer

Summary

Background

Goals

Proposed Solution

1. Database Timezone Consistency

2. Deployment-Level Timezone Configuration

3. User-Level Timezone Settings

4. Display Handling

5. UI Configuration and Management

Open Questions

Replies: 2 comments · 1 reply

This comment has been hidden.

This comment has been hidden.

Uh oh!

spikecurtis Nov 19, 2024 Collaborator

matifali
Nov 14, 2024
Maintainer

Replies: 2 comments 1 reply

spikecurtis
Nov 19, 2024
Collaborator