I have a timestamp column 'submitted_on' with default as now().
I have set the heroku TZ to my zone and added a php user ini with the same timezone.
But the database is still using UTC timezone. I see this when I ran this sql:
show timezone;
Is there a fix? Or this is how heroku databases work? Also I'm using free dynos.
Setting a TZ config var only affects the Dynos environment, as the database is located on a different machine, it has no effect.
Generally speaking, you should always keep servers clocks running on UTC, store all times in UTC, and perform any timezone/locale changes in your application framework.
The parameter timezone is determined when the database cluster is created.
You can either change the value in postgresql.conf, or you can use ALTER SYSTEM as a superuser to change the value.
I don't know if Heroku allows you either of these options.
Related
I need to permanently change my postgreSQL db timezone from AEST to UTC, the instance is on AWS rds.
On my AWS RDS postgreSQL parameter group, the timezone shows UTC but when i run
show timezone; it returns my local time zone which is AEST
the sql SET TIMEZONE='UTC'; only change the session, so what's the right way to change the timezone to UTC permanently?
this link shows changing the parameter group value should work? https://aws.amazon.com/premiumsupport/knowledge-center/rds-change-time-zone/
thanks
A "source" of 'client' means that when your client connects, it sets the timezone it wants to use. This will override anything you do globally and permanently on the database side, as the client can always change their own setting for this.
If you tell us what your client is and how it is configured, someone may be able to help you change this behavior. For example if it is a libpq-based client, then having the PGTZ environment variable set will cause this behavior.
I'd like to know how to permanently change the timezone on postgresql -- using set timezone TO 'UTC' only changes it in current session, upon restarting it's back to my region timezone. If i change the postgresql.config file under data to:
datestyle = 'iso, dmy'
#intervalstyle = 'postgres'
timezone = 'UTC'
#timezone_abbreviations = 'Default'
Even if i stop the postgresql-x64-12 service, save the file, and restart service, it goes back to my region timezone afterwards.
Thank you!
The documentation says:
The TimeZone configuration parameter can be set in the file postgresql.conf, or in any of the other standard ways described in Chapter 19. There are also some special ways to set it:
The SQL command SET TIME ZONE sets the time zone for the session. This is an alternative spelling of SET TIMEZONE TO with a more SQL-spec-compatible syntax.
The PGTZ environment variable is used by libpq clients to send a SET TIME ZONE command to the server upon connection.
So either you changed the value in a wrong postgresql.conf, or you have the PGTZ environment variable set on the client side.
Another alternative is a SET TIME ZONE command in the .psqlrc file.
I am trying to change the RDS timezone to UTC,
I'm using an SQL Client called DBeaver
I tried the following two commands -
1. Configuration Parameter Name -
SET timezone TO 'UTC';
and
2. Standard SQL Command -
SET TIME ZONE 'UTC';
But the select now(); command still doesn't return the UTC time
I am referring this answer -
postgres default timezone
Tried the following -
echo $PGTZ
SET TIME ZONE 'UTC';
ALTER DATABASE your_db_name SET timezone TO 'UTC';
Maybe you are using a connection pool, and session settings get cleared when the session returns to the pool.
You could try something like
ALTER ROLE your_user SET timezone = 'UTC';
You must reconnect for this to take effect.
Also, check if the environment variable PGTZ is set in your environment. It will override the database settings.
If all that doesn't do the trick, consider the possibility that the server's time is off.
I have a postgresql database that I deploy scripts to using flyway. I use the maven flyway plugin to launch the database build against the target database. In that build I have scripts that do things like:
create table my_table(
my_date_time timestamp with time zone not null
);
insert into my_table(my_date_time)
select '2000-01-01';
The postgresql database timezone is set to UTC. My client machine (that runs the maven/flyway build) is running CEST (UTC+2:00).
When the scripts run, the database interprets the string literal above as '1999-12-31 22:00:00+00:00' and writes that to storage.
It seems that the jdbc client connection created by flyway is not setting its client timezone to UTC, but is taking the timstamp string and interpreting it as '2000-01-01 00:00:00+02:00'.
How can I set the client timezone on the jdbc connection created by flyway to UTC? Is there a setting that can be placed in my flyway.conf file?
If I change my local machine timezone to UTC the problem goes away, but I'd rather not do that on my development workstation.
A colleague suggested the following
mvn -Duser.timezone=UTC flyway:migrate
Instead of just giving it a date, which postgres has to interpret, it would be better to fully specify the timestamp:
insert into my_table(my_date_time)
select '2000-01-01T00:00:00+00';
If that is not possible, you could try running mvn with -Duser.timezone=UTC but fully specifying the timestamp is the better option as it leaves no room for misinterpretation or misconfiguration.
Another way is to set session timezone in migration script itself
SET timezone TO 'UTC';
i use flyway CLI in a script. so setting correct timezone to the corresponding environment variable before executing flyway command works for me:
export TZ=GMT
G'Day,
I was setting up a new machine today with an environment identical to the other developer machines and I installed postgreSQL using a debian package. After more than an hour's worth of troubleshooting I found that our application kept crashing on the new machine because it's datestyle value in postgresql.conf was set to 'ISO, MDY' whereas on the old machines it was 'ISO, DMY'. I checked the values of #LC_TIME# (in fact all locale values) and they're the same across the machines. Any idea what could've caused this difference in the setting?
Thanks!
Two points, first if you send dates to PostgreSQL in yyyy-mm-dd format, datestyle is irrelevant.
The initial value comes from the postgresql.conf which is set up by the installation of the package (initdb or the rpm/deb/etc). The best option here is to change it, but to correct your application to send dates to the db in yyyy-mm-dd format.