to_milliseconds

Applies to VAST Cluster 5.5.

Functions › Date and time functions › Interval constructors. Returns an interval of n milliseconds, the same as INTERVAL n MILLISECOND. Add it to a date or a timestamp, or subtract it, to move by that many milliseconds.

Syntax

to_milliseconds(n)

Returns: INTERVAL.

Same as: INTERVAL n MILLISECOND for a constant n.

Set up the examples

The examples connect with the ADBC driver, as in VAST Query Engine (ADBC), and work in a schema called docs_sql_fn_date_time_to_milliseconds. Set QE_ENDPOINT, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY and VASTDB_BUCKET (SQL reference), and run the blocks in order in one Python session. Below each block is the output you should see.

This block connects, defines the run() and plan() helpers, and creates a table of five tasks. Each has a start time (ts), a date (d), a whole number (n, an INTEGER) and a number with a fraction (f, a DOUBLE). Row 4 has no values:

import os
import re

import adbc_driver_manager
import adbc_driver_manager.dbapi as dbapi
import adbc_driver_vastdb

BUCKET = os.environ["VASTDB_BUCKET"]
SCHEMA = f'"{BUCKET}/docs_sql_fn_date_time_to_milliseconds"'

conn = dbapi.connect(
    driver=adbc_driver_vastdb.get_driver_path(),
    db_kwargs={
        "vast.db.endpoint": os.environ["QE_ENDPOINT"],
        "vast.db.access_key": os.environ["AWS_ACCESS_KEY_ID"],
        "vast.db.secret_key": os.environ["AWS_SECRET_ACCESS_KEY"],
    },
    autocommit=True,
)

def server_message(e):
    """The server's message in a driver error, without the request ID or the echoed statement."""
    text = re.sub(r"\[req=0x[0-9a-f]+\]: ", "", str(e))
    found = (re.search(r'message: "(.*?)", request_id', text, re.S)
             or re.search(r"description: (.*)\)", text, re.S))
    message = found.group(1) if found else text.strip().splitlines()[-1]
    message = re.sub(r"^Plan query: '.*?' failed with: ", "", message, flags=re.S)
    message = re.split(r"\\n|\n", message)[0].replace('\\"', '"')
    return message.replace(BUCKET, "<bucket>")

def run(sql):
    """Run one statement. Print the rows it returns, or the error."""
    try:
        with conn.cursor() as cur:
            cur.execute(sql)
            rows = cur.fetchall() if cur.description else []
    except (adbc_driver_manager.Error, OSError) as e:
        print(f"{type(e).__name__}: {server_message(e)}")
    else:
        print(rows)

def plan(sql):
    """Print the plan without its ~N Rows lines: the table's row count, which can still be 0 just after an insert."""
    with conn.cursor() as cur:
        cur.execute("EXPLAIN " + sql)
        steps = cur.fetchall()[0][1]
    print("\n".join(line for line in steps.splitlines() if "Rows" not in line))

TABLE = f"{SCHEMA}.tasks"
run(f"CREATE SCHEMA IF NOT EXISTS {SCHEMA}")
run(f"CREATE TABLE IF NOT EXISTS {TABLE} (id BIGINT, ts TIMESTAMP, d DATE, n INTEGER, f DOUBLE)")
run(f"INSERT INTO {TABLE} VALUES "
    "(1, TIMESTAMP '2026-02-28 23:15:00', DATE '2026-01-31', 1, 1.5), "
    "(2, TIMESTAMP '2026-03-01 08:30:45.123456', DATE '2026-03-01', -2, -0.25), "
    "(3, TIMESTAMP '2024-12-30 12:00:00', DATE '2024-12-30', 0, 0.0), "
    "(4, NULL, NULL, NULL, NULL), "
    "(5, TIMESTAMP '2024-02-29 00:00:00', DATE '2024-02-29', 12, 0.000001)")

[]
[]
[(5,)]

What it does

An INTERVAL has three parts: months, days and a time part. ADBC returns it as an Arrow month-day-nanosecond interval, which Python prints as MonthDayNano(months=..., days=..., nanoseconds=...). The parts are kept apart: they're combined only when the interval is added to a date or a timestamp.

to_milliseconds(n) puts n thousandths of a second in the time part, which Python shows in nanoseconds: to_milliseconds(2) is nanoseconds=2000000. TIMESTAMP '2024-02-29 00:00:00' + to_milliseconds(1) is 2024-02-29 00:00:00.001000, and DATE '2026-01-31' + to_milliseconds(1) is 2026-01-31 00:00:00.001000, a TIMESTAMP.

n can have a fraction: to_milliseconds(1.5) is one and a half milliseconds. The result keeps whole microseconds: to_milliseconds(0.0000001) is 0.

The time part isn't turned into days: normalized_interval(to_milliseconds(100)) is still 100 milliseconds. epoch(to_milliseconds(1)) is 0.001 seconds.

NULLs and edge cases

The same cases, as the cluster returns them. They use the table and helpers from Set up the examples:

run(f"SELECT id, to_milliseconds(f) FROM {TABLE} WHERE id = 4")
run("SELECT to_milliseconds(NULL), to_milliseconds(0), to_milliseconds(-1), to_milliseconds('2'), to_milliseconds(CAST(2 AS SMALLINT)), to_milliseconds(CAST(2 AS BIGINT))")
run("SELECT to_milliseconds(1.5), to_milliseconds(-0.5), to_milliseconds(0.0000001)")
run("SELECT to_milliseconds('NaN'::DOUBLE)")
run("SELECT to_milliseconds(9223372036854.775)")
run("SELECT to_milliseconds(9223372036855)")
run("SELECT to_milliseconds(DATE '2026-01-01')")

[(4, None)]
[(None, MonthDayNano(months=0, days=0, nanoseconds=0), MonthDayNano(months=0, days=0, nanoseconds=-1000000), MonthDayNano(months=0, days=0, nanoseconds=2000000), MonthDayNano(months=0, days=0, nanoseconds=2000000), MonthDayNano(months=0, days=0, nanoseconds=2000000))]
[(MonthDayNano(months=0, days=0, nanoseconds=1500000), MonthDayNano(months=0, days=0, nanoseconds=-500000), MonthDayNano(months=0, days=0, nanoseconds=0))]
OSError: Interval value nan milliseconds out of range
[(MonthDayNano(months=0, days=0, nanoseconds=-9223372036854775616),)]
[(MonthDayNano(months=0, days=0, nanoseconds=-9223372036854551616),)]
InternalError: Binder Error: No function matches the given name and argument types 'to_milliseconds(DATE)'. You might need to add explicit type casts.

Examples

An interval of f milliseconds for each task:

run(f"SELECT id, f, to_milliseconds(f) FROM {TABLE} ORDER BY id LIMIT 10")

[(1, 1.5, MonthDayNano(months=0, days=0, nanoseconds=1500000)), (2, -0.25, MonthDayNano(months=0, days=0, nanoseconds=-250000)), (3, 0.0, MonthDayNano(months=0, days=0, nanoseconds=0)), (4, None, None), (5, 1e-06, MonthDayNano(months=0, days=0, nanoseconds=0))]

Move each start time by f milliseconds, and the last day of January by one millisecond:

run(f"SELECT id, ts, ts + to_milliseconds(f) FROM {TABLE} ORDER BY id LIMIT 10")
run("SELECT DATE '2026-01-31' + to_milliseconds(1), TIMESTAMP '2024-02-29 00:00:00' + to_milliseconds(1), TIMESTAMP '2024-02-29 00:00:00' - to_milliseconds(1)")

[(1, datetime.datetime(2026, 2, 28, 23, 15), datetime.datetime(2026, 2, 28, 23, 15, 0, 1500)), (2, datetime.datetime(2026, 3, 1, 8, 30, 45, 123456), datetime.datetime(2026, 3, 1, 8, 30, 45, 123206)), (3, datetime.datetime(2024, 12, 30, 12, 0), datetime.datetime(2024, 12, 30, 12, 0)), (4, None, None), (5, datetime.datetime(2024, 2, 29, 0, 0), datetime.datetime(2024, 2, 29, 0, 0))]
[(datetime.datetime(2026, 1, 31, 0, 0, 0, 1000), datetime.datetime(2024, 2, 29, 0, 0, 0, 1000), datetime.datetime(2024, 2, 28, 23, 59, 59, 999000))]

Keep only the tasks that, moved by f milliseconds, end after midnight on 1 March 2026:

run(f"SELECT id FROM {TABLE} WHERE ts + to_milliseconds(f) > TIMESTAMP '2026-03-01 00:00:00' ORDER BY id LIMIT 10")

[(2,)]

How it runs in VAST

The Query Engine runs on the cluster's CNodes, and a query on a table starts with a scan in VAST DataBase (VAST_SCAN). VAST DataBase can evaluate a comparison of a column with a constant, but not a function of a column, so an interval built from a column is always computed by the Query Engine:

• In the SELECT list, the scan reads the column and the Query Engine computes to_milliseconds() for each row it returns.
• In WHERE, the scan sends the columns for every row, and a FILTER step in the Query Engine computes ts + to_milliseconds(f) and keeps the rows that match. No rows are skipped in storage.

The plan of the WHERE example shows the FILTER step above the scan:

plan(f"SELECT id FROM {TABLE} WHERE ts + to_milliseconds(f) > TIMESTAMP '2026-03-01 00:00:00'")

┌───────────────────────────┐
│         PROJECTION        │
│    ────────────────────   │
│             #2            │
│                           │
└─────────────┬─────────────┘
┌─────────────┴─────────────┐
│           FILTER          │
│    ────────────────────   │
│ ((ts + to_milliseconds(f))│
│  > '2026-03-01 00:00:00': │
│        :TIMESTAMP)        │
│                           │
└─────────────┬─────────────┘
┌─────────────┴─────────────┐
│         VAST_SCAN         │
│    ────────────────────   │
│    Function: VAST_SCAN    │
│                           │
│        Projections:       │
│             ts            │
│             f             │
│             id            │
│                           │
└───────────────────────────┘

Make it faster

• Put the interval on the constant side. A comparison of the raw column with a constant, such as ts > TIMESTAMP '2026-01-15 00:00:00' + to_days(30) or ts > TIMESTAMP '2026-03-01 00:00:00' - INTERVAL 1 HOUR, is pushed down to VAST DataBase, so rows that don't match never leave storage. ts + INTERVAL 1 HOUR > ... needs the FILTER step. The plan of the same shape with to_milliseconds:

plan(f"SELECT id FROM {TABLE} WHERE ts > TIMESTAMP '2026-03-01 00:00:00' - to_milliseconds(1)")

┌───────────────────────────┐
│         VAST_SCAN         │
│    ────────────────────   │
│    Function: VAST_SCAN    │
│      Projections: id      │
│                           │
└───────────────────────────┘

• Store the result if you filter on it often. When the number of milliseconds comes from a column, as f does here, there's no single constant to compare with. Compute ts + to_milliseconds(f) when you write the rows and keep it in its own TIMESTAMP column; a comparison of that column with a constant is pushed down.

Limitations and errors

• NaN fails. to_milliseconds('NaN'::DOUBLE) fails with Interval value nan milliseconds out of range. Filter such values out first.
• Microseconds at most. A fraction smaller than a microsecond is dropped: to_milliseconds(0.0000001) is 0.
• Very large values come back wrong. to_milliseconds(9223372036855) doesn't fail: it returns a wrong, negative interval, and so does to_milliseconds(9223372036854.775). Express spans that long in days, months or years.
• No INTERVAL columns. A table can't have an INTERVAL column: CREATE TABLE fails with INTERVAL type is not supported in table definitions. Store the number of milliseconds in a number column and build the interval with to_milliseconds() in the query.

run(f"CREATE TABLE {SCHEMA}.durations (id BIGINT, v INTERVAL)")

InternalError: Binder Error: INTERVAL type is not supported in table definitions. Column "v" has type: INTERVAL

Similar functions

run("SELECT to_milliseconds(1) = INTERVAL 1 MILLISECOND, to_milliseconds(1) = to_microseconds(1000)")
run(f"SELECT id, to_milliseconds(CAST(id AS INTEGER)) = INTERVAL (id) MILLISECOND FROM {TABLE} ORDER BY id LIMIT 10")
run("SELECT date_add(TIMESTAMP '2024-02-29 00:00:00', to_milliseconds(1)), normalized_interval(to_milliseconds(100))")

[(True, True)]
[(1, True), (2, True), (3, True), (4, True), (5, True)]
[(datetime.datetime(2024, 2, 29, 0, 0, 0, 1000), MonthDayNano(months=0, days=0, nanoseconds=100000000))]

Clean up:

run(f"DROP TABLE IF EXISTS {SCHEMA}.durations")
run(f"DROP TABLE IF EXISTS {TABLE}")
run(f"DROP SCHEMA IF EXISTS {SCHEMA}")
conn.close()

[]
[]
[]

See also

• The other interval constructors: to_years, to_quarters, to_months, to_weeks, to_days, to_hours, to_minutes, to_seconds, to_microseconds.
• Date and time functions: all the date and time functions.
• Where filters run and pushdowns.
• EXPLAIN: how to read a plan.