How to get correct timezone id of current session - postgresql

On my local machine have CET timezone (postgres config same), when i run request SELECT current_setting('TIMEZONE') from java i get 'GMT-1' which is incorrect. I cant use that id in java. How to get from postgresql 'GMT+1' instead?
Is there command to get ISO timezone name/id?

Related

How to set timezone on postgresql jdbc connection created by flyway?

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

Ubuntu timezone changed but mongodb still prints datetime based on previous timezone

I used following commands to change timezone in my Ubuntu 16.04 server
sudo ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime and tzselect
After typing date I get the correct datetime.
But on mongodb when I print time of recently added document by res.ops[0]._id.getTimestamp() I still get the datetime prior to the timezone change.
I restarted mongodb and the server itself. But still no change. And I am using node.js as backend.
You need to save the time as UTC and then on the server side get the document with time and apply to it your wanted timezone. That way you decouple timezones from your data.

Database timezone not using TZ

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.

Clojure: java.jdbc can't connect to Postgres after changing OS timezone to UTC

When I set my timezone on my server to UTC via timedatectl set-timezone UTC and restart Postgres server, I can connect via psql and verify that select now() returns the correct value.
When I try to start my Clojure app and run a query, I get the following error:
Acquisition Attempt Failed!!! Clearing pending acquires.
While trying to acquire a needed new resource, we failed
to succeed more than the maximum number of allowed
acquisition attempts (30). Last acquisition attempt exception:
org.postgresql.util.PSQLException: FATAL: invalid value for parameter "TimeZone": "UTC"
I am using the following database libraries in my app:
[org.postgresql/postgresql "9.4.1208"]
[clojure.jdbc/clojure.jdbc-c3p0 "0.3.2"]
[org.clojure/java.jdbc "0.6.1"]
The error looks like it comes from Postgres, but only happens when connecting via the Clojure app.
Everything works if I return the OS timezone to America/New_York
Take a look at
postgres default timezone
See what timezone names are understood by the database:
SELECT * FROM pg_timezone_names;

Postgres now() returns +03 timezone but show timezone returns GMT

prompt$ date
Mon Oct 7 17:32:24 UTC 2013
prompt$ psql -U postgres
postgres=# show timezone;
TimeZone
----------
GMT
(1 row)
postgres=# select now();
now
-------------------------------
2013-10-07 20:32:42.354384+03
(1 row)
Why is it returning it in +03 timezone format? What am I obviously missing here?
EDIT: I solved the problem, but a question still remains. Here is what happened:
I had changed the system's OS timezone, without restarting the postgres server. Previous OS timezone was indeed +03. After I restarted postgres, it worked correctly. But it is a strange situation: postgresql.conf has not any timezone explicitly defined and the client (psql) should should always output timestamps in the timezone reported by "show timezone". So there is still this unexplained question:
Why psql was reporting GMT as timezone setting but displayed timestamps in the OS new timezone. Is this expected behaviour?
This is certainly odd behavior, largely because I would have expected show timezone to show the same timezone as now() showed. My recommendation is try to reproduce the situation and then email the PostgreSQL list or file a bug report. It sounds like you might be able to cause this by changing your system timezone while PostgreSQL is running. A reload or restart might fix the problem.
I also second the notion of watching out for ALTER USER ... SET TIMEZONE, but on top of that you can also ALTER DATABASE ... SET TIMEZONE and even ALTER FUNCTION ... SET TIMEZONE