Is `timestamp > now() - 30s` valid SQL?
Usually no. In PostgreSQL use NOW() - INTERVAL '30 seconds'. In MySQL use NOW() - INTERVAL 30 SECOND. In SQL Server use DATEADD(second, -30, SYSUTCDATETIME()).
If you searched for timestamp > now() - 30s, you are likely building a rolling freshness check, replay guard, or short polling window. The query intent is right, but the exact syntax is database-specific. In production, use explicit interval syntax and keep your source timestamps in UTC to avoid silent timezone drift.
In 2026, most last-30-second filters fail for two reasons: mixed time units and column type mismatch. Always validate whether your event data is epoch seconds, epoch milliseconds, or a native SQL timestamp before comparing against NOW().
PostgreSQL
SELECT * FROM events WHERE created_at >= NOW() - INTERVAL '30 seconds';
MySQL
SELECT * FROM events WHERE created_at >= NOW() - INTERVAL 30 SECOND;
SQL Server
SELECT * FROM events WHERE created_at >= DATEADD(second, -30, SYSUTCDATETIME());
Need a current reference value? Use current UTC timestamp. For API contract patterns, see current epoch time API guide. To decode logged values quickly, open Unix timestamp to date.
Need both conversion directions while debugging SQL filters? Open the main epoch converter tool.
Running this query on a schedule? Validate your polling schedule with Cron Expression Builder.
Usually no. In PostgreSQL use NOW() - INTERVAL '30 seconds'. In MySQL use NOW() - INTERVAL 30 SECOND. In SQL Server use DATEADD(second, -30, SYSUTCDATETIME()).
The most common causes are timezone mismatch, storing local time instead of UTC, and comparing a string field instead of a true timestamp column.
Use >= when you need inclusive boundaries. Use > for strict boundaries. Keep it consistent with downstream metrics and retry logic.
A 10-digit value is usually seconds and a 13-digit value is milliseconds. Convert and verify against UTC output before shipping query logic.