Time Zone

How the time_zone setting affects query results, loads, and the times shown in SHOW commands, system tables, and tools.

Time zones show up in several places, and they don't all follow the same rule. One distinction, wall-clock versus instant, explains the rest.

Wall-clock and instant

VeloDB works with two kinds of time value:

• Wall-clock: a calendar reading like 2026-06-26 10:00:00, with no zone attached. DATE and DATETIME columns store this. It is shown exactly as written, and time_zone never changes it.
• Instant: an absolute point in time, stored as a count of seconds since 1970-01-01 00:00:00 UTC. It has no hours or minutes until you pick a zone. now(), load timestamps, and job times are instants.

A zone only matters when converting between the two. The same instant becomes a different wall-clock in each zone:

SET time_zone = '+00:00';     SELECT from_unixtime(1000000000); -- 2001-09-09 01:46:40
SET time_zone = 'Asia/Tokyo'; SELECT from_unixtime(1000000000); -- 2001-09-09 10:46:40

The stored instant is identical. Only the shown clock changes.

Time zone variables

Variable	Writable	What it does
time_zone	Yes	The active zone. Converts instants to and from wall-clock.
system_time_zone	No (read-only)	Reports the server's own zone, detected at startup. Informational.

SELECT @@time_zone;                 -- the active zone
SET time_zone = 'America/New_York'; -- this session only
SET GLOBAL time_zone = '+00:00';    -- default for future sessions

time_zone starts from system_time_zone but is yours to change. Changing it never touches stored data; it only changes how instants are converted.

Stored table data

DATE and DATETIME columns are wall-clock. Write 2026-06-26 10:00:00, read back 2026-06-26 10:00:00, in any session, under any time_zone. Changing time_zone does not rewrite or reinterpret stored values.

Time functions

These functions convert instants to or from wall-clock, so they use your session time_zone:

Function	Effect
now(), current_timestamp(), curdate()	Current instant as wall-clock in your zone
unix_timestamp(datetime)	Reads the datetime as wall-clock in your zone, returns the instant
from_unixtime(instant)	Converts an instant to wall-clock in your zone
convert_tz(dt, from, to)	Converts between two zones you name; ignores time_zone

now() is fixed once per query, so a distributed query returns the same value everywhere.

Loads

Most load methods accept their own timezone, so a load can parse incoming datetimes under a fixed zone. Omit it and the load uses your session time_zone.

Load method	How to set it
Stream Load	timezone HTTP header. See Stream Load.
Broker Load / S3 Load	timezone in PROPERTIES. See Broker Load.
Routine Load	timezone in job PROPERTIES. See Routine Load.
MySQL Load	timezone property. See MySQL Load.

curl --location-trusted -u <user>:<password> \
    -H "timezone: America/New_York" \
    -T data.csv \
    http://<host>:<port>/api/<db>/<table>/_stream_load

INSERT, SELECT INTO OUTFILE, and EXPORT have no per-load option; set time_zone in your session first.

Times in SHOW commands and system tables

Job and load metadata (create time, pause time, and so on) are instants. They have no zone until you view them, and the zone depends on how you read them:

• SHOW commands use your session time_zone.
• System tables and table functions use the global time_zone (SET GLOBAL time_zone), not your session value.

So the same job's create time can look different two ways:

SET time_zone = 'Asia/Tokyo';

SHOW ROUTINE LOAD;                                   -- create time in your session zone
SELECT * FROM information_schema.routine_load_jobs;  -- create time in the global zone
SELECT * FROM jobs("type"="insert");                 -- create time in the global zone

The underlying instant is the same; only the shown clock differs.

Query audit

The audit_log table follows the same rule as other system tables: query times use the global time_zone, not your session value. Each row's time is written as text once, so existing rows keep the zone they were written with even if you change the global setting later.

The Time(ms), CpuTimeMS, and similar columns are durations in milliseconds, not clock times.

VeloDB Console

The Console shows every time in the viewer's browser zone, and time-range pickers read your selection in that same zone. Two consequences:

• The same event shows a different clock to viewers in different regions. It is still one moment.
• A Console time can differ from a SQL query of the same value, because the Console uses the browser zone and SQL uses time_zone.

To change what the Console shows, change the browser or OS zone, not time_zone.

Accepted zone formats

• Named zones: America/New_York, Europe/London, Asia/Tokyo.
• Fixed offsets: +09:00, -05:30, +00:00.
• Aliases: UTC and GMT mean UTC. CST resolves to Asia/Shanghai (+08:00), not US Central; for US Central, use America/Chicago.

Named zones follow Daylight Saving Time. For example, America/Los_Angeles shifts from -08:00 to -07:00 in spring and back in autumn, so the same wall-clock maps to a different instant across the year. To pin a constant offset and opt out of DST, use a fixed offset like -08:00 instead of a named zone.

At a glance

Surface	Zone it uses
Stored DATE/DATETIME	None (shown as written)
now(), unix_timestamp, from_unixtime	Session time_zone
Loads	The load's timezone, else session time_zone
SHOW commands	Session time_zone
System tables and table functions (routine_load_jobs, jobs(), audit_log)	Global time_zone
VeloDB Console	Viewer's browser zone

See also

• convert_tz converts a datetime between two named zones inside a query.
• Stream Load, Broker Load, Routine Load, and MySQL Load accept a per-load timezone.