I use postgres for the rails app and I have a unix timestamp in postgresql db. I have a requirement to select and group by the dd-mm-yyyy and by month name.
Consider I have the following unix timestamp
1425148200
and I would need to change this to datetime and I used to_timestamp which returned
2015-02-28 18:30:00 UTC
and I tried to convert the datetime to local timezone using
::timestamp without time zone AT TIME ZONE 'IST'
but that did not give time in required timezone and instead it returned
2015-02-28 16:30:00 UTC
and I tried to get the date part using ::date which returned
Sat, 28 Feb 2015
So please help me get the dd-mm-yyyy in specified timezone and month name(March) from the unix timestamp.
Thanks in Advance!
select to_char(to_timestamp('1425148200')::timestamptz at time zone 'UTC-5:30','DD-MM-YYYY & of course Month')
01-03-2015 & of course March
It is postgres mistake I guess
according to http://www.postgresql.org/docs/7.2/static/timezones.html
Related
Based on my understanding of the documentation, I am expecting the TIMEZONE function to convert any timestamp from UTC (by default) to 'timezone'.
I know for a fact that the timestamp columns of the server I'm pulling data from are set to UTC. Therefore, if I convert the timestamp column to EST, I should see a five hour difference between UTC and EST (according to worldtimebuddy).
However, when I run the following query
select
time_column
, timezone('est', time_column) as to_est
from
my_table
order by
time_column desc
limit 1
I get
sent_at
to_est
2022-11-15 17:50:26.280
2022-11-15 22:50:26.280
If I'm interpreting this correctly, the result is telling me that UTC is five hours behind EST, when really, UTC is five hours ahead of EST (right?).
In other words, I was expecting
sent_at
to_est
2022-11-15 17:50:26.280
2022-11-15 12:50:26.280
Why am I seeing a -5 hour difference from UTC to EST instead of +5?
instead of timezone use
convert_timezone('EST', time_column)
That is the way redshift shows in the manual
the syntax is
CONVERT_TIMEZONE ( ['source_timezone',] 'target_timezone', 'timestamp')
but the source time zone is by default UTC, so you don't need to add it to your code
I need to convert 2021-10-03 15:10:00.0 as 2021-10-03T15:10:00-04:00
I tried with.
from_utc_timestamp(from_unixtime(unix_timestamp('2021-10-03 15:10:00.0', "yyyy-MM-dd HH:mm:ss.S"),"yyyy-MM-dd'T'HH:mm:ssXXX"),"America/New_York")
I got Null value
Any suggestions please
from_utc_timestamp can accept timestamp or compatible string (yyyy-MM-dd HH:mm:ss.S), or bigint, not this: "yyyy-MM-dd'T'HH:mm:ssXXX"
Hive timestamps are timezoneless. Once you converted from UTC to America/NY, the timezone information is lost, only you know in which timezone it is, having timestamp converted it is already impossible to derive the timezone from it.
You can concatenate with timezone, conversion like this returns what you need but it works for particular date only. In December -05:00 timezone should be usedm not +04:00:
date_format(from_utc_timestamp('2021-10-03 15:10:00.0',"America/New_York"),"yyyy-MM-dd'T'HH:mm:ss+04:00") --This is wrong!!!
From_utc_timestamp is Daylight saving aware. It can be -05:00 or -04:00 depending on the date.
Consider this example, first returns 5, second returns 4:
select (unix_timestamp("2020-01-01 12:00:00.0")-unix_timestamp(from_utc_timestamp("2020-01-01 12:00:00.0","America/New_York")))/60/60
select (unix_timestamp("2020-10-19 12:00:00.0")-unix_timestamp(from_utc_timestamp("2020-10-19 12:00:00.0","America/New_York")))/60/60
So, you can get current time zone corresponding to America/New_York for the same timestamp and concatenate it with converted timestamp:
select concat(date_format(from_utc_timestamp('2021-10-03 15:10:00.0',"America/New_York"),"yyyy-MM-dd'T'HH:mm:ss"),'+0',
--get hrs shift
(unix_timestamp("2021-10-03 15:10:00.0")-unix_timestamp(from_utc_timestamp("2021-10-03 15:10:00.0","America/New_York"))) div 3600,':00')
Result:
2021-10-03T11:10:00+04:00
It should work correctly with different timestamps taking into account daylight saving time for America/New_York.
as said in the title I would like to have a query that returns the value of the time stamp in my current time zone (even according summer time!).
my_table is:
|timestamp|name|value|property1|property2|
|---|---|---|---|---|
|2021-08-01 00:00:00+00|10|0.44|0|0|
|2021-08-01 00:05:00+00|15|0.76|0|0|
|2021-08-01 00:10:00+00|12|0.28|0|0|
(Don't ask me why I cannot put this table directly in markdown...prob cause the dates)
Now for example if I have to select the 24h corresponding to the entire day in my time zone at the moment my solution is:
SELECT timestamp AT TIME ZONE 'CEST',name,value
FROM my_table
WHERE name IN (10,11,12)
AND timestamp BETWEEN '2021-08-01 00:00:00+02' AND '2021-08-02 00:00:00+02'
ORDER BY timestamp DESC
As you can see there is a problems here:
I have to specify every time if I is CEST or CET (now is CEST here)
and then I have to add +02 at the end of the dates (or +01 in CET)
There is a way to avoid this conceptual repetition?? any suggestion even to improve the query is appreciated
the command SELECT version(); gives me back PostgreSQL 12.7
Set your session's timezone appropriately.
set timezone TO 'Europe/Berlin';
select '2021-08-01 00:00:00+00'::timestamptz;
timestamptz
------------------------
2021-08-01 02:00:00+02
select '2021-12-01 00:00:00+00'::timestamptz;
timestamptz
------------------------
2021-12-01 01:00:00+01
select '2021-08-01 00:00:00'::timestamptz;
timestamptz
------------------------
2021-08-01 00:00:00+02
What is your session timezone set to now?
I have been able to convert a TIMESTAMP field that is in UTC to CST using:
SELECT
TIMESTAMP(started_at) AS UTC,
TIMESTAMP_SUB(TIMESTAMP (started_at), INTERVAL 5 HOUR) AS CST
This returns:
ROW
UTC
CST
1
2020-05-17 13:07:22 UTC
2020-05-17 08:07:22 UTC
The second TIMESTAMP displays the correct date and time but UTC still shows. What is the simplest way to replace 'UTC' with 'CST' or, alternatively, remove 'UTC' altogether since I don't need the designation in the field itself?
You can use a plain sql replace function inline
select replace(TIMESTAMP_SUB(TIMESTAMP (started_at), INTERVAL 5 HOUR), 'UTC','') AS CST
The above searches the result of your expression (provided in your question) for 'UTC' and replaces it with nothing ''. You could also replace it with 'CST' as you noted.
Obligatory warning: I believe your query will only be correct half the year as long as DST is observed? You might want to look into sys.time_zone_info and its reference on the MSDN.
My advise is to convert the timestamp to a datetime local value:
select datetime(started_at, 'America/Chicago') as started_at_cst
Note that the time zone is not stored in the data value. Instead, this encodes the value in the string.
If you want to include the time zone value, I have found that the best approach is to use a string (argghh!). The following constructs a string:
format_timestamp('%F %X%z', started_at, 'America/Chicago') as started_at_str
which can be converted easily into a timestamp for date/time calculations:
timestamp(started_at_str)
I could appreciate a second pair of eyes on my Postgres syntax.
Database stores timestamp in UTC. I'm trying to convert from UTC to Eastern Daylight Time EDT, but the output is not accurate.
Here's my syntax:
SELECT
to_char(((timestamp AT TIME ZONE 'UTC') AT TIME ZONE 'EDT'), 'MM/DD/YYYY HH24:MI')
FROM table_name
Record TimeStamp:
09/10/2016 12:00
Query Output:
09/10/2016 16:00
Desired Output:
09/10/2016 08:00
Thanks for your assistance.
Saying AT TIMEZONE twice is redundant since it will just convert from whatever the current timezone (which you suggest is UTC) to UTC then to EDT.
The fact that you feel the need to convert it to UTC tells me you're not storing it as a TIMESTAMP WITH TIMEZONE. Check if this is the case. If it is, that's likely your problem. From the docs:
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.
Basically, if you don't specify, it assumes it's from your current timezone by default, not UTC. It's possible you entered a UTC timestamp and it assumed it was EDT.