IF between time in SAP HANA - sql

Question

SELECT SERIES_ROUND(TO_TIMESTAMP(DATE_TIME,'YYYYMMDDHH24MISS'),'INTERVAL 30 MINUTE') as TIME
returns a result like "Mon Nov 02 2020 00:00:00 GMT+0100 (CET)"
what i need is to return shift name
if time between 08:00:00 and 16:30:00 return SHIFT A
if time between 16:30:00 and 00:15:00 return SHIFT B
if time between 00:15:00 and 08:00:00 return SHIFT C
any help appreciated

Answer 1

Something like the following should work:
SELECT CASE WHEN CAST(TO_TIMESTAMP(DATE_TIME,'YYYYMMDDHH24MISS') AS TIME) BETWEEN TO_TIME ('08:00:00', 'HH24:MI:SS') AND TO_TIME ('16:30:00', 'HH24:MI:SS') THEN 'Shift A'
WHEN CAST(TO_TIMESTAMP(DATE_TIME,'YYYYMMDDHH24MISS') AS TIME) BETWEEN TO_TIME ('00:15:00', 'HH24:MI:SS') AND TO_TIME ('08:00:00', 'HH24:MI:SS') THEN 'Shift C'
ELSE 'Shift B' END

Answer 2

This reads a bit like a query that should process the clock-in times of workers or something similar.
Therefore I used clock_ins as the name for the timestamped events in my example code.
To make this work correctly, it helps to make the different computations and data type conversions step by step:
WITH clock_ins AS (
SELECT 1 AS ID, to_timestamp('20200101080012', 'YYYYMMDDHH24MISS' ) AS DATE_TIME FROM DUMMY
UNION ALL
SELECT 2 AS ID, to_timestamp('20200101043135', 'YYYYMMDDHH24MISS' ) AS DATE_TIME FROM DUMMY
UNION ALL
SELECT 3 AS ID, to_timestamp('20200101120056', 'YYYYMMDDHH24MISS' ) AS DATE_TIME FROM DUMMY
UNION ALL
SELECT 4 AS ID, to_timestamp('20200101170012', 'YYYYMMDDHH24MISS' ) AS DATE_TIME FROM DUMMY
),
clock_ins_rounded AS (
SELECT
ID
, SERIES_ROUND(DATE_TIME,'INTERVAL 30 MINUTE') AS clock_in
, to_time(SERIES_ROUND(DATE_TIME,'INTERVAL 30 MINUTE')) AS clock_in_time
FROM
CLOCK_INS)
SELECT
id
, CLOCK_IN
, clock_in_time
, CASE
WHEN clock_in_time BETWEEN to_time('08:00:00') AND to_time('16:30:00') THEN
'SHIFT A'
WHEN ( clock_in_time >= to_time('16:30:00')
OR clock_in_time <= to_time('00:15:00')) THEN
'SHIFT B'
WHEN clock_in_time BETWEEN to_time('00:15:00') AND to_time('08:00:00') THEN
'SHIFT C'
ELSE
'NO SHIFT'
END AS SHIFT
FROM
clock_ins_rounded;
ID|CLOCK_IN |CLOCK_IN_TIME|SHIFT |
--|-------------------|-------------|-------|
1|2020-01-01 08:00:00| 08:00:00|SHIFT A|
2|2020-01-01 04:30:00| 04:30:00|SHIFT C|
3|2020-01-01 12:00:00| 12:00:00|SHIFT A|
4|2020-01-01 17:00:00| 17:00:00|SHIFT B|
The first WITH-clause CLOCK_INS generates the test data and includes at least one case for every rule the OP mentioned.
The second WITH-clause CLOCK_INS_ROUNDED performs the "rounding" to the 30 minutes intervals via the SERIES_ROUND function (good choice!). It also takes the result from this rounding and creates a time of day version from it via the TO_TIME() function. This column is then made available as CLOCK_IN_TIME.
The final and main SELECT clause projects the computed CLOCK_IN timestamp, the CLOCK_IN_TIME column, and also the assigned shifts.
The shifts are assigned via a CASE statement. To make this work correctly it is important to use TIME data types for the comparisons. Leaving out the TO_TIME( ) conversion for each of the conditions would lead to implicit type conversion and the comparison would be calculated as string comparisons which is NOT what you want for this use case.
The other important bit to notice is the rule for SHIFT B. This rule describes an interval between a time before and a time after midnight. As we are dealing with instants of time (actually not even that - it's just time of day data we use) here and not with intervals the BETWEEN comparison would not work correctly for the case of BETWEEN 16:30 AND 00:15.
Therefore, we need to take care of this in the code and translate this condition to LARGER (LATER) THAN 16:30 OR SMALLER (EARLIER) THAN 00:15.
Finally, it is a good idea to include an others branch in CASE statements, so that it is easy to detect data that is not handled by any rule or when rules are not "catching" data that they should have caught.
In summary, these are the main points to consider for this requirement:
implement one computation at a time and avoid overly nested expressions (to make the code easier to be read and understood)
use an appropriate data type for the comparison semantic (e.g. use a TIME data type when using time comparisons like "earlier" or "later). This includes both the data to be processed as well as the comparison data in the code.
when dealing with time-related data types, make sure to understand the differences between date-time, intervals, and time-of-day data
when using CASE statements, include an others case for data that is not handled by the other rules