with demo_times as (
select timestamp('2022-03-29 23:00:00') t
union all select timestamp('2022-03-29 23:15:00')
union all select timestamp('2022-03-29 23:45:00'))
select d.t
, timestamp_trunc(timestamp_add(d.t, interval 30 minute), hour) t_rounded
from demo_times d
Produces:
t
t_rounded
2022-03-29T23:00:00.000+00:00
2022-03-29T23:00:00.000+00:00
2022-03-29T23:15:00.000+00:00
2022-03-29T23:00:00.000+00:00
2022-03-29T23:45:00.000+00:00
2022-03-30T00:00:00.000+00:00
If you just want to remove the minutes/seconds after the hour, timestamp_trunc would be a good solution.
I’m not sure there’s an equivalent to round timestamps in BQ that you might have seen on Qlik, etc.
This flow does round “Up” to the next hour if the timestamp is closer, by adding 30 minutes to the timestamp and flooring the hour:
If the timestamp is 00:30:00 or less, the output of the formula will return a timestamp that is truncated to the hour of the original timestamp value.
As an example, if we pass through 01:20:00:
Adding 30 minutes to the timestamp produces 1:40:00,
Then we truncate the hour value and receive 01:00:00.
If we submit 01:45:00:
Adding 30 minutes to the timestamp produces 2:15:00,
Then we truncate the hour value and receive 2:00:00.
The formula and interval to add would have to be adjusted to whatever scope you’re rounding to, this particular formula would produce similar results to round(timestamp,1/24). You could use this same process for other intervals, but the logic would have more than one parameter. If you wanted to round to 30 minute intervals you could add 15 Minutes to the source timestamp and floor to ½ hour intervals.
An alternative could be to convert to unixtime, cast to numeric, round to your desired microsecond level, and cast back to timestamp.
The “type” influences more how the results interact with the Looker explore. (Type can affect the filter options, etc). It can also influence the SQL Generated [eg: CAST( x AS TIMESTAMP) in the generated query].
The datatype refers to how the data exists in the database table itself. The docs state this is most useful to “increase query performance”. The specifics of how aren’t detailed, but I imagine it means less unnecessary casting if the datatype on your db table matches the required input for whatever function you’re using (date_trunc, as an example). As an example, if your db column is already a timestamp format, when using a time dimension_group it won’t need to cast the column to timestamp before using subsequent date format functions.
date_trunc(month,cast(x as timestamp))
would just be generated as
date_trunc(month,x)
That is my current understanding of its importance.
Type is something output form and datatype is something tells about input value form. Type is a mandatory thing, we should define what kind of data will come out.
datatype is good to define, especially when there is a date or timestamp.
I think we should always try to define datatype and type, isn’t ?