TL;DR:
realtime.send() doesn't set inserted_at, so it falls back to now() cast to a timestamp, which is the session's local time. Replay compares it against UTC, so if the database (or session) isn't UTC, replay returns the wrong messages or nothing at all.
With the timezone set to Asia/Kolkata, a message sent now is stored 5.5h in the future and replay returns nothing, even with since: 0.
alter database postgres set timezone to 'Asia/Kolkata';
-- new session
select realtime.send('{"a":1}', 'ev', 'room', true);
select inserted_at, now() at time zone 'utc' from realtime.messages;
-- inserted_at is 5.5h ahead
Everything else already treats inserted_at as UTC (replay, partitions, realtime.authorize), and the same mismatch was fixed for commit_timestamp in #527. #2202 switches the default to clock_timestamp(), but that's still local time.
TL;DR:
realtime.send()doesn't setinserted_at, so it falls back tonow()cast to atimestamp, which is the session's local time. Replay compares it against UTC, so if the database (or session) isn't UTC, replay returns the wrong messages or nothing at all.With the timezone set to
Asia/Kolkata, a message sent now is stored 5.5h in the future and replay returns nothing, even withsince: 0.Everything else already treats
inserted_atas UTC (replay, partitions,realtime.authorize), and the same mismatch was fixed forcommit_timestampin #527. #2202 switches the default toclock_timestamp(), but that's still local time.