SQLite timestamp > now() - 30s in 2026

If you searched for timestamp > now() - 30s, the SQL intent is correct, but SQLite syntax is different from PostgreSQL or MySQL. In 2026 production apps, the right predicate depends on whether your data is stored as ISO text, Unix seconds, or Unix milliseconds.

For ISO text columns, compare against datetime('now', '-30 seconds'). For integer epoch columns, use unixepoch() so both sides use the same unit. This prevents silent bugs where 10-digit seconds are compared to 13-digit milliseconds.

SQLite-safe query examples

ISO text timestamp column

SELECT *
FROM events
WHERE created_at >= datetime('now', '-30 seconds');

Unix seconds integer column

SELECT *
FROM events
WHERE created_at_epoch >= unixepoch('now', '-30 seconds');

Unix milliseconds column

SELECT *
FROM events
WHERE created_at_ms >= (unixepoch('now') * 1000) - 30000;

Related EpochConverter pages

For a cross-database overview, see timestamp now minus 30s. Compare SQLite against PostgreSQL syntax and MySQL syntax.

Need to validate raw values while debugging? Open the main epoch converter tool.

Related developer tool

Running this filter inside scheduled jobs? Validate run cadence with Cron Expression Builder.

Frequently Asked Questions

Does SQLite support `timestamp > now() - 30s` directly?

Not exactly. SQLite does not use PostgreSQL interval syntax. Use datetime('now', '-30 seconds') or unixepoch() based on your column type.

What if my column stores Unix seconds?

Compare against unixepoch('now', '-30 seconds'). Keep both sides in seconds so the predicate remains index-friendly and accurate.

What if my column stores Unix milliseconds?

Use (unixepoch('now') * 1000) - 30000 for a rolling 30-second threshold and compare against your millisecond integer column.

How do I avoid timezone bugs?

Store timestamps in UTC and only convert for display in the UI. SQLite's now/unixepoch helpers are UTC-based by default.