Postgresql DATABASE timezone - postgresql

Question

Does anyone know what this actually does?
There appears to be two different timezones, a Session timezone and a Database time zone. The former is clear, it causes timezones with timestamp to be converted from a text representation in psql to UTC.
But what does the Database time zone do?
It can be changed with
ALTER DATABASE database_name SET TIMEZONE='zone';
Is Database Timezone just some sort of default for the Session Timezone? Or does it affect how timestamps are stored? My understanding is that the psql session timezone defaults to the client computer timezone.
There is also the question of the 99.9% of usages that do not use psql. Say JDBC. When and how are offsets added. But that is not this question.
Timezones are tricky, and never well documented.

Answer 1

This is covered in the documentation. In particular:
For timestamp with time zone, the internally stored value is
always in UTC […].
Admittedly mentioning UTC is a bit misleading, I'd prefer to say that a timestamptz represents an instant, an exact fixed point in time, without regard to calendar or location (timezone). It's just an offset since an epoch. Very much like a Date in Java or JavaScript, or better: like an Instant (Java, JavaScript).
[For literal timestamptz values, if] no time zone is stated in the
input string, then it is assumed to be in the time zone indicated by
the system's TimeZone
parameter,
and is converted to UTC using the offset for the timezone zone.
When a timestamp with time zone value is output, it is always
converted from UTC to the current timezone zone, and displayed as
local time in that zone.
The TimeZone configuration
parameter
can be set in the file postgresql.conf, or in any of the other
standard ways described in Chapter
20.
TimeZone (string):
Sets the time zone for displaying and interpreting time stamps. The
built-in default is GMT, but that is typically overridden in
postgresql.conf; initdb will install a setting there corresponding
to its system environment.
So the timezone setting affects conversions of timestamps from and to text, both via casting and the via to_char/to_timestamp function calls, in SQL execution.
It does not affect storage.
Looking at chapter 20, in particular Setting Parameters, shows that there are many more than just two places to set the timezone configuration variable.
The most fundamental way to set these parameters is to edit the file postgresql.conf. […]
Parameters set in this way provide default values for the cluster. The
settings seen by active sessions will be these values unless they are
overridden. The following sections describe ways in which the
administrator or user can override these defaults.
[The file postgresql.auto.conf] is intended to be edited
automatically, not manually. This file holds settings provided through
the ALTER SYSTEM
command.
[…] Settings in postgresql.auto.conf override those in
postgresql.conf.
[T]here are two commands that allow setting of defaults on a
per-database or per-role basis:
The ALTER DATABASE command
allows global settings to be overridden on a per-database basis.
The ALTER ROLE command
allows both global and per-database settings to be overridden with
user-specific values.
Values set with ALTER DATABASE and ALTER ROLE are applied only when
starting a fresh database session. They override values obtained from
the configuration files or server command line, and constitute
defaults for the rest of the session.
Once a client is connected to the database, PostgreSQL provides […]
SQL commands […] to interact with session-local configuration
settings:
The SET command allows
modification of the current value of those parameters that can be set
locally to a session; it has no effect on other sessions.
The documentation of the SET command details how this may be limited to the current session, the current transaction, or the currently executing function.
A client would have to explicitly set this to use the client computer's system timezone for the session. JDBC does this, for example.

Answer 2

(another post answering exactly the questions from the OP, taken from the comments of my other answer)
What does the Database time zone do?
It's a configuration setting that is applied when starting a fresh session (connection), overrides the server defaults, and constitutes the default for the rest of the session.
Is Database Timezone just some sort of default for the Session Timezone?"
Yes.
Or does it affect how timestamps are stored?
No. timestamp with timezone represents an instant, a fixed point in time, without regard to calendar or location (timezone). It's just an offset since an epoch.
My understanding is that the psql session timezone defaults to the client computer timezone.
No: only when your client explicitly sets it - like JDBC does.
What happens for JDBC, for cols timestamptz, values Date vs String?
I've not used it myself and don't know how it does conversion of raw serialisation to java objects. But I would presume that when you query timestamptz as a Date, the timezone setting doesn't matter. When you query timestamptz as a String, the timezone would apply ("When a timestamp with time zone value is output, it is always converted from UTC to the current timezone zone, and displayed as local time in that zone.").
When you query timestamp as a String, it would not apply. And you shouldn't query a timestamp as a Date (JDBC might assume UTC? Postgres does not!)
How do you show the current Database Timezone?
See How do you view the configuration settings of a PostgreSQL database? or Query for all the Postgres configuration parameters‘ current values?

Answer 3

Manual ALTER DATABASE part.
The remaining forms change the session default for a run-time
configuration variable for a PostgreSQL database. Whenever a new
session is subsequently started in that database, the specified value
becomes the session default value. The database-specific default
overrides whatever setting is present in postgresql.conf or has been
received from the postgres command line. Only the database owner or a
superuser can change the session defaults for a database. Certain
variables cannot be set this way, or can only be set by a superuser.
meaning if the new connection not explicitly override the value, then the new value will become session default.
Like ALTER DATABASE test15 SET TIMEZONE='Singapore'; if you are still in session, you will still have the previous timezone value, if you quit the session, reenter agagin, then the new TIMEZONE is Singapore.
SELECT
name,
category,
short_desc,
extra_desc,
context
FROM
pg_settings
WHERE
name = 'TimeZone' gx
return.
-[ RECORD 1 ]---------------------------------------------------------------
name | TimeZone
category | Client Connection Defaults / Locale and Formatting
short_desc | Sets the time zone for displaying and interpreting time stamps.
extra_desc |
context | user
The context is user level, which means any connection can use set command change it.
So when query the interval value like timestamptz column > now(). the return values will become different for connections in differenent timezone.
psql session timezone defaults to the client computer timezone.
if you not explicitly set it, the default will be database level timezone parameter value.
There is also the question of the 99.9% of usages that do not use
psql. Say JDBC. When and how are offsets added. But that is not this
question.
psql is same as JDBC, both are client. they can change timezone use set command, if the connection is superuser or owner, then they can change database default, which means other connection will follow the new default.
However each connection can still use set command to change the timezone paramter.
does it affect how timestamps are stored?
If your timestamp from string literal,then no. if your timezone from timestamptz then yes. First query result is the same, second is not.
begin;
set time zone 'Singapore';
select '2022-01-01 11:30'::timestamp;
reset time zone;
select '2022-01-01 11:30'::timestamp;
commit;
begin;
set time zone 'Singapore';
select now()::timestamp;
reset time zone; --default not 'Singapore'
select now()::timestamp;
commit;