Scalingo App TZ Variable and Managed PostgreSQL Session Timezone Interoperability

Timezone Propagation Behavior

No, Scalingo does not automatically propagate the application-level TZ environment variable to your managed PostgreSQL session. The TZ variable modifies the container's runtime environment and the behavior of language-specific time APIs (e.g., Node.js, Python, Ruby), but it has no effect on the external PostgreSQL instance, which defaults to UTC for all new sessions.

Recommended Synchronization Approach

To ensure consistency between your application's civil-time logic and the database, you should avoid relying on the database's session timezone for business logic. Instead, follow these implementation standards:

• Use TIMESTAMPTZ: Define your columns as TIMESTAMP WITH TIME ZONE. PostgreSQL stores these values in UTC internally and converts them to the session timezone upon retrieval.
• Explicit Session Configuration: If your application relies on database-side functions (like CURRENT_TIMESTAMP) to match the app's TZ, you must issue a SET TIME ZONE command immediately after establishing a connection.

Implementation via Connection Pool

Rather than calling SET TIME ZONE on every query, configure your connection pool's initialization logic to run the command once per connection:

-- Example SQL command to run on connection initialization
SET TIME ZONE 'Europe/Paris';

Scheduler Execution and UTC Drift

The Scalingo Scheduler executes jobs in UTC by default. This creates a disconnect if your job logic assumes the TZ variable is active or if the job triggers based on a local-time calculation. To prevent drift:

1. Normalize to UTC: Write all Scheduler logic using UTC and only convert to the target timezone at the presentation layer.
2. Manual Offset: If the job must perform civil-time calculations, explicitly load the TZ variable within the job script to ensure the runtime clock is adjusted before querying the database.

Verification Steps

To verify the current mismatch, run the following commands in your environment:

• Database Default: Run SHOW TIMEZONE; via a database client to confirm the managed default (likely UTC).
• Runtime Comparison: Compare the output of SELECT now(); from the database against the current time returned by your application's native time API.

Diagnostic Note: Please specify if you are using a connection pooler (like PgBouncer) in transaction mode, as this prevents the use of SET TIME ZONE for session persistence.