The shift_summaries view would pick the "most future" recurring event if it
found multiple possible representative events:
- 2025年12月25日
- 2026年01月01日 <--today
- 2026年01月08日
- 2026年01月15日 <--representative event
But that didn't make much sense if there was a recurring event that is happening
soon. So now it picks the next event if there are any, and then falls back to
the previous event if not.
Using the case statement to sort is a bit hard to validate, but you can use the
following sql to validate:
withfake_eventsas(SELECT*FROM(VALUES(1,now()+'-1 week'::interval),(2,now()+'1 minute'::interval),(3,now()+'1 week'::interval),(4,now()+'2 weeks'::interval))ASevents(id,starts_at))select*,starts_at>now()fromfake_eventsorderby(casewhenstarts_at>now()thenstarts_atelse'infinity'::timestampend)asc,(casewhenstarts_at<=now()thenstarts_atelse'-infinity'::timestampend)desc;
It will sort event 2 on top, here. Changing all the intervals to be negative so
all the timestamps are in the past, it will still sort event 2 on top because
it's now the most recent.
The infinity and -infinity are used to reject other rows. If starts_at is
in the past, other rows will compare their starts_at to infinity in the
first case which means it will never sort first, and then the reverse for the
second case. You kind of get two sets of data:
First case:
infinity
--- now ---
2026年01月01日 <--earliest row
2026年01月08日
2026年01月15日
Second case:
2025年12月25日 <--latest row
--- now ---
-infinity
-infinity
-infinity
I also snuck in a fix for a flaky test.
The `shift_summaries` view would pick the "most future" recurring event if it
found multiple possible representative events:
- 2025年12月25日
- 2026年01月01日 <--today
- 2026年01月08日
- 2026年01月15日 <--representative event
But that didn't make much sense if there was a recurring event that is happening
soon. So now it picks the next event if there are any, and then falls back to
the previous event if not.
Using the case statement to sort is a bit hard to validate, but you can use the
following sql to validate:
```sql
with fake_events as (
SELECT
*
FROM (
VALUES
(1, now() + '-1 week'::interval),
(2, now() + '1 minute'::interval),
(3, now() + '1 week'::interval),
(4, now() + '2 weeks'::interval)
) AS events (id, starts_at)
)
select *, starts_at > now()
from fake_events
order by
(case when starts_at > now() then starts_at else 'infinity'::timestamp end) asc,
(case when starts_at <= now() then starts_at else '-infinity'::timestamp end) desc;
```
It will sort event 2 on top, here. Changing all the intervals to be negative so
all the timestamps are in the past, it will still sort event 2 on top because
it's now the most recent.
The `infinity` and `-infinity` are used to reject other rows. If `starts_at` is
in the past, other rows will compare their `starts_at` to `infinity` in the
first `case` which means it will never sort first, and then the reverse for the
second `case`. You kind of get two sets of data:
```
First case:
infinity
--- now ---
2026年01月01日 <--earliest row
2026年01月08日
2026年01月15日
Second case:
2025年12月25日 <--latest row
--- now ---
-infinity
-infinity
-infinity
```
I also snuck in a fix for a flaky test.