Is there a good way to generate the minimum possible timestamp in redshift?
This is what I came up with:
SELECT to_timestamp(0, 'utc')
Related
We are storing date time in "2022-11-30T17:30:00.000Z" format in var char column i know its totally wrong but I want to rectify the mistake and use the column as timestamp with time zone.
I Tried using column::timestamp AT TIME ZONE 'Asia/Calcutta' but still date and time is wrong as it does not considers +5:30 in my time zone.please suggest how can i transform the column or if i could use the same column.
select dtm from dashboard where (select dtm::timestamp AT TIME ZONE 'Asia/Calcutta')::date between '2022-11-30' and '2022-11-30' order by dtm;
Usually we use EXTRACT (FROM YEAR date_column) = 2000 (let it be 2000 year). Also we can add EXTRACT (MONTH FROM date_column) = 1 (let it be January). Also we can extract a day - EXTRACT (DAY FROM date_column) = 5 (let it 5). But is it possible to use the pattern for this data? How does it look like in Postgres SQL
Say we have the table Shipment, the columns - date_payment, quantity, sum.
I'd like to get the table that content all shipments for 01.01.2020
How to query this table with data format 'YYYY-MM-DD', not using EXTRACT-function?
If the date column is a date type then:
SELECT * FROM some_table WHERE date_col = '2020-01-01';
If the column is timestamp or timestamptz then:
SELECT * FROM some_table WHERE date_trunc('day', date_col) = '2020-01-01'
Beware that with timestamptz time zones come into play when doing the date_trunc. From here date_trunc:
When the input value is of type timestamp with time zone, the truncation is performed with respect to a particular time zone; for example, truncation to day produces a value that is midnight in that zone. By default, truncation is done with respect to the current TimeZone setting, but the optional time_zone argument can be provided to specify a different time zone. The time zone name can be specified in any of the ways described in Section 8.5.3.
For a timestamp value per the above link:
A time zone cannot be specified when processing timestamp without time zone or interval inputs. These are always taken at face value.
Using psycopg to connect to a Redshift DB I am trying to group by date (in a specific time zone, given at query time). All date_times are stored without time zone (and correspond to UTC timestamps).
I have been trying the following:
SELECT DISTINCT DATE(TIME_ZONE(%(time_zone)s, date_time_dim.timestamp)) AS date,
SUM(meals.sugar_in_g) AS total_sugar
FROM meals
INNER JOIN date_time_dim
ON meals.created_at = date_time_dim.timestamp
WHERE meals.patient_id=%(patient_id)s
AND date_time_dim.timestamp >= %(utc_start_date_time)s
AND date_time_dim.timestamp <= %(utc_end_date_time)s
GROUP BY date
ORDER BY date ASC;
with the following query dictionary:
utc_start_date_time UTC-converted date time
utc_end_date_time UTC-converted date time
patient_id an integer
time_zone, a string, ex: 'US/Hawaii'
The goal being to have one entry for each date (in the given time zone).
What I tried gives me:
function time_zone("unknown", timestamp without time zone) does not exist
What am I missing ?
Edit: This is the same with CONVERT_TIME_ZONE, with and without source time_zone, with and without type casting time_zone to VARCHAR.
The function in Redshift to return a timestamp in a different timezone is TIMEZONE() not TIME_ZONE() - see https://docs.aws.amazon.com/redshift/latest/dg/Date_functions_header.html
I am using PostgreSQL 9.5. I have a table which is almost 20GB's. It has a primary key on the ID column which is an auto-increment column, however I am running my queries on another column which is a timestamp... I am trying to select/update/delete on the basis of a timestamp column but the queries are very slow. For example: A select on this table `where timestamp_column::date (current_date - INTERVAL '10 DAY')::date) is taking more than 15 mins or so..
Can you please help on what kind of Index should I add to this table (if needed) to make it perform faster?
Thanks
You can create an index with your clause expression:
CREATE INDEX ns_event_last_updated_idx ON ns_event (CAST(last_updated AT TIME ZONE 'UTC' AS DATE));
But, keep in mind that you're using timestamp with timezone, cast this type to date can let you get undesirable side effects.
Also, remove all casting in your sql:
select * from ns_event where Last_Updated < (current_date - INTERVAL '25 DAY');
I really need to store local date and time (aircraft wheels up date and time) and the utc offset so I can convert to utc to calculate intervals (flight duration). People travel on local time and you need utc for cross time zone computations. I had hoped to use timestamptz but it absolutely does not work for this purpose. It converts everything to a function of the postgres time zone. In my case this is yyyy-dd-mm hh:mi:ss-07.
However, I investigated timetz just to cover all the bases. It stores exactly what I need. It preserves the local time while providing the offset to utc. Except that now I need two columns instead of one to store the information.
My questions are:
Why do the timestamptz and the timetz functions give different results?
Is there a way to make the timestamptz include the local time zone offset rather than the system time zone offset?
Here are the queries that illustrate the difference:
select cast('2015-05-01 11:25:00 america/caracas' as timestamptz)
-- 2015-05-01 08:55:00-07
;
select cast('2015-05-01 11:25:00 america/caracas' as timetz)
-- 11:25:00-04:30
;
I personally find the wording timestamp with time zone confusing when trying to understand PostgreSQL's timestamptz, because it doesn't store any time zone. According to the docs:
All timezone-aware dates and times are stored internally in UTC. They are converted to local time in the zone specified by the TimeZone configuration parameter before being displayed to the client.
Notice, on that page, that the storage characteristics and limits of timestamp and timestamptz are identical.
In my head, to keep things straight, I translate timestamptz to "timestamp in the real world", and plain timestamp to "you probably didn't mean to use this type" (because, so far, I've only found myself needing to store timestamps that are related to the real world.)
So:
Why do the timestamptz and the timetz functions give different results?
It appears to be because PostgreSQL didn't feel they were allowed to make timetz work like timestamptz does:
The type time with time zone is defined by the SQL standard, but the definition exhibits properties which lead to questionable usefulness.
My guess is that some of these "properties" are the ones that they don't like, and you do.
And:
Is there a way to make the timestamptz include the local time zone offset rather than the system time zone offset?
There's no offset being stored for timestamptz values. They're just real-world timestamps. So the way to store the local time zone is the way you've already thought of: store it separately.
create table my_table (
happened timestamptz,
local_time_zone varchar
);
select happened at time zone 'UTC', happened at time zone local_time_zone
from my_table;