How to get server local time in char(8) format hh:mm:ss in every Postgres version.
In 9.1 it works:
select current_time::char(8)
returns proper local time 13:46:00
In 9.5 it returns 3 hour different time:
10:46:00
select current_time, version() returns
"10:48:40.181735+00";"PostgreSQL 9.5.2, compiled by Visual C++ build 1800, 32-bit"
and
"13:48:51.775138+03";"PostgreSQL 9.1.2 on x86_64-unknown-linux-gnu, compiled by gcc-4.4.real (Debian 4.4.5-8) 4.4.5, 64-bit"
Update
Both servers use default postgres.conf settings for time.
postgres.conf does not contain timezone settings.
in 9.5 Windows 10 it contains
#timezone = 'GMT'
#timezone_abbreviations = 'Default'
in 9.1 Debian it contains
#timezone = '(defaults to server environment setting)'
#timezone_abbreviations = 'Default'
How to get server local time in 9.5 when default postgresql.conf file is used ?
It looks like server does not use OS setting in 9.5
How to force 9.5 to ask timezone from OS and return time in this zone?
Ask for the time zone you want:
select current_time at time zone 'brt';
timezone
--------------------
08:26:16.778448-03
If you need a string:
select to_char(current_timestamp at time zone 'brt', 'HH24:MI:SS');
to_char
----------
08:32:07
Notice that the to_char function does not accept the time type. Use timestamp instead.
Get the OS local time zone from the shell. In Linux:
$ date +%Z
BRT
In psql:
=> \! date +%Z
BRT
If there is psql at the client:
psql -c "\! date +%Z" --host localhost --dbname=cpn --no-password
BRT
It is necessary a .pgpass file to avoid supplying the password.
If timezone is not specified in postgresql.conf or as a server command-line option, the server attempts to use the value of the TZ environment variable as the default time zone. If TZ is not defined or is not any of the time zone names known to PostgreSQL, the server attempts to determine the operating system's default time zone by checking the behavior of the C library function localtime(). The default time zone is selected as the closest match among PostgreSQL's known time zones. (These rules are also used to choose the default value of log_timezone, if not specified.) source
This means that if you do not define a timezone, the server attempts to determine the operating system's default time zone by checking the behavior of the C library function localtime().
If timezone is not specified in postgresql.conf or as a server command-line option, the server attempts to use the value of the TZ environment variable as the default time zone.
I believe you need to remove the # in #timezone = 'GMT'
And replace GMT with '(defaults to server environment setting)'
Because '(defaults to server environment setting)' is undefined and thus the server attempts to determine the operating system's default time zone by checking the behavior of the C library function localtime().
To obtain the local time calculated with the defined timezone:
select current_time, version();
To obtain the local time calculated with a specified timezone:
select current_time at time zone 'US/Eastern';
To obtain the defined timezone:
SELECT current_setting('TIMEZONE');
To assign the timezone that you want to use:
set timezone='US/Eastern';
You can see the different timezones here
Related
I'm encountering an issue with reading timestamps properly, without any automatic conversions on Presto on EMR.
Example: within the AWS Glue catalog, i have a table with timestamp columns in UTC time (data type timestamp). When querying in Athena, they return as expected. When querying in Presto on EMR (EMR 5.26, Presto 0.220), there is an automatic conversion happening to a different time zone.
Presto docs describe a method of disabling this behavior here - https://prestosql.io/docs/current/language/timestamp.
The legacy semantics can be enabled using the deprecated.legacy-timestamp config property. Setting it to true (the default) enables the legacy semantics, whereas setting it to false enables the new semantics.
They outline their result differences with this option set to true vs false at the bottom
Query: SELECT TIME '10:00:00 Asia/Kathmandu' AT TIME ZONE 'UTC'
Legacy result: 04:30:00.000 UTC
New result: 04:15:00.000 UTC
After including deprecated.legacy-timestamp set to true in my EMR config (within presto-config), I'm still getting the new result according to this test query, (and my UTC timestamps are still being auto converted).
Any suggestions on what else i need to do to enable the legacy timestamp behavior?
Legacy timestamp behavior is still the default, you can track current state at https://github.com/prestosql/presto/issues/37. Apparently Athena evaluates timestamps as Presto would do when run with UTC session zone.
Since Presto 317 you can force client session zone with a config property:
sql.forced-session-time-zone=UTC
For all Presto versions, you can set client session zone. How to do this depends on the particular client in use. For example, with presto-cli you would typically do
java -Duser.timezone=UTC -jar presto-cli.jar
The execution of following SQL in Oracle:
SELECT TZ_OFFSET('Europe/Brussels') from dual;
returns the value +02:00
Note that this function can be used for any timezone in Olsson notation. It's not about the database server.
I was wondering if there exists a similar function in MS Sql Server where you can ask the offset of a given timezone (in the microsoft timezone notation).
From SQL 2016 onward, and in Azure SQL Database, you can achieve this with:
SELECT DATENAME(tz, SYSDATETIMEOFFSET() AT TIME ZONE 'Romance Standard Time')
-- Output: '+02:00'
Notice the time zone names are Windows time zone identifiers, not the IANA TZ (aka Olson) identifiers. For more on the differences, see the timezone tag wiki.
If you want to use IANA TZ identifiers, or if you are using an older version of SQL Server that doesn't have the AT TIME ZONE function, then you can use my SQL Server Time Zone Support project, with the following:
SELECT DATENAME(tz, Tzdb.SwitchZone(SYSDATETIMEOFFSET(), 'Europe/Brussels'))
-- Output: '+02:00'
Also, note that an offset can only be computed for a time zone at a particular reference point. In my examples, you can see I have chosen the current system time with SYSDATETIMEOFFSET(). (The current time is implicit with Oracle's TZ_OFFSET function.)
I'm using SQL Server 2016 at Amazon AWS. My emails are being sent with incorrect times when sent from my pupper at Amazon. When I try to recreate this bug locally the times are correct. Here is an example of how I use at time zone.
getDate() at time zone 'utc' at time zone u.timezone
where u.timezone is the user's timezone and u refers to an aliased table users.
The times being outputted are at UTC time, so I see 7:36pm instead of 2:36pm (they are formatted with MomentJS)
I don't really know where to start with this one, sorry guys and gals.
UPDATE
My server is sending the correct time (with the correct timezone offset) to the email factory. When the server creates the emails, times are formatted using MomentJS. The barebones moment() function will take a time with a timezone offset (-5:00) and adjust it to the local machine's local time. Local time on my machine is EST, but in Amazon (where the email is being created) is not. Thus I must use moment.parseZone().
From the MomentJS docs:
If your date format has a fixed timezone offset, use moment.parseZone:
moment.parseZone("2013-01-01T00:00:00-13:00");
This results in a date with a fixed offset:
"2013-01-01T00:00:00-13:00"
Since I can't see this change until it is pushed onto our dev environment, I won't be able to know if this fixed it, but I think this was the problem.
My server was sending the correct time (with the correct timezone offset) to the email factory. When the server created the emails, times were formatted using MomentJS.
The barebones moment() function takes a time with a timezone offset (-5:00) and adjusts it to the local machine's local time.
Local time on my machine is EST, but in Amazon (where the email is being created) is not. Thus I must use moment.parseZone().
Changing to moment.parseZone() fixed this issue. Problem solved.
In the SQLite IDE SQL window, I've written the instruction to return the the equivalence of .NET DateTime.Now, which is CURRENT_TIMESTAMP.
Let's say it is 10:47:00 in local time, that is, GMT -4:00 (on summertime), otherwise it is GMT -5:00.
The result of my query:
select current_timestamp
returns 2010-09-23 14:47:00, regardless of my local machine time.
How can I make SQLite use my local time instead of GMT?
Thanks everyone! =)
Use select datetime(current_timestamp, 'localtime');
You can get more info on the date/time functions here
CREATE TABLE DIALOGUE_TABLE(EXPIRE_TIME TIMESTAMP);
Following code snippet is inside stored proc :
PO_EXPIRETIME :- OUT PARAM of procedure a varchar2
SELECT TO_CHAR(SYS_EXTRACT_UTC(EXPIRE_TIME))
INTO PO_EXPIRETIME
FROM DIALOGUE_TABLE;
When I run Stored Proc from server using EXEC and print PO_EXPIRETIME timestamp is proper with UTC format.
But when I call stored procedure from OCCI and client the timestamp recieved is not same but that is the actual timestamp in table not UTC formatted.
Maybe something I am missing but what I don't know?
Is there something in client side I need to do?
If the column is declared as a TIMESTAMP and not, say, a TIMESTAMP WITH TIME ZONE or TIMESTAMP WITH LOCAL TIME ZONE, the timestamp that is stored in the table will not have a time zone component. As a result, SYS_EXTRACT_UTC will convert the timestamp to UTC using the session time zone which is something that is controlled by the client and may be different on different client machines. I suspect that if you run
SELECT SessionTimeZone
FROM dual;
from your OCCI application and from your SQL*Plus session that you will end up with different results which is causing the strings returned to be different.
If you want the string that is returned to be independent of the client machine, I would tend to suggest storing the time zone in the database column. Is changing the schema definition to use a TIMESTAMP WITH TIME ZONE an option? Barring that, you could ensure that every client machine has the same time zone configured and/or run an explicit ALTER SESSION, i.e.
ALTER SESSION
SET time_zone = '-05:00';
in the stored procedure to ensure that the conversion is always done from a particular time zone.