It's currently 11:05 UTC. When I call "SELECT CURRENT_TIMESTAMP" on our Heroku Postgres DB it says 11:10 UTC.
How is that massive difference possible? Do we have to manually set the current time?
current_timestamp function relies on system time and returns time of the beginning of transaction (if any). in your case probably system time is not sync with ntp servers. you can check system time with command 'date'.
Heroku said the NTP client on this machine stopped working. They've restarted it and it's working again.
Related
Running SELECT current_timestamp in Dbeaver running PostgreSQL Version 12.2 gives me a datetime result that is 8 Days, 2 Hours and 4 minutes in the past compared to my system time. I am not sure if I need to tweak a time setting somewhere...
There are two explanations I can think of:
the system time on the database server is off
the timezone parameter is set to a weird value in your client session
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
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.
I'm getting a little confused by postgresql timezones
i was checking the dates in some rows and i noticed the timezone -4 in them
but my actual timezone is -3
the government made changes to the daylight saving timezones and the tzdata files where changes
the system date was fine but postgres don't notice the change until i restarted it
i tried setting it with
set TIME ZONE LOCAL
but it sill got the bad timezone -4
select extract(epoch from now()),now();
date_part | now
------------------+------------------------------
1335240339.68894 | 2012-04-24 00:05:39.68894-04
(1 fila)
but after i restarted postgresql
# select extract(epoch from now()),now();
date_part | now
----------------+-------------------------------
1335240403.672 | 2012-04-24 01:06:43.672002-03
(1 fila)
my timezone was always
show timezone;
TimeZone
------------------
America/Santiago
(1 fila)
may i need to restart postgres every time tzdata info is changed?
According to this FAQ entry, PostgreSQL is coming with the latest tzdata database. In order to keep it up to date, one should install minor PostgreSQL releases on a regular basis.
It is also possible to have PostgreSQL compiled with system tzdata database support using the --with-system-tzdata configure option.
In both cases, running server will not monitor for changes in the tzdata databases, so you'll have to explicitly notify it via the restart.
How do you set the time in Postgres? I've set the time zone in Postgres to Eastern Standard Time using set timezone='-5'. However, the time was 45 minutes off where it should have been. Thinking Postgres was getting the time from Linux, I set the date in Linux using date -s="24 AUG 2011 13:48" and rebooted, and yet the problem persists.
Any ideas?
Postgresql will get its time (not necessarily time zone) setting from the OS, yes.
If your Linux machine has internet access, you can install NTP to keep the time in sync. Simply setting the time locally should be persisted back to the BIOS RTC, though.