Start of 2026 Unix Timestamp: 1767225600 (UTC)

Quick answer

1767225600 is the Unix timestamp for:

2026-01-01T00:00:00.000Z

Use it when you mean the UTC start of calendar year 2026.

Meaning	Value
Unix seconds	1767225600
Unix milliseconds	1767225600000
ISO 8601 UTC	2026-01-01T00:00:00.000Z
Inclusive lower bound for 2026	>= 1767225600
Exclusive upper bound for 2026	< 1798761600
Last whole second before 2026	1767225599

For a full-year 2026 UTC query, use:

WHERE event_time >= 1767225600
  AND event_time <  1798761600

That includes every instant in 2026 and excludes 2027-01-01T00:00:00Z.

What 1767225600 means

Unix time counts forward from 1970-01-01 00:00:00 UTC. The value 1767225600 is the exact instant when UTC crosses from 2025 into 2026.

That sounds simple, but this number is usually copied into places where the details matter:

• analytics filters for "all of 2026"
• billing or subscription start dates
• log searches around New Year's Eve
• database migrations with hard-coded boundaries
• automated tests that need a stable year-start fixture
• API payloads that use Unix seconds instead of ISO strings

The safest wording is:

1767225600 is the inclusive UTC lower bound for 2026.

It is not automatically the local start of 2026 for every user, office, or reporting timezone.

Seconds, milliseconds, microseconds, and nanoseconds

The public Unix timestamp is usually shown in seconds. Some systems need a different unit.

Unit	Start of 2026 value	Typical use
Seconds	1767225600	Unix tools, many APIs, JWT-style claims, SQL epoch values
Milliseconds	1767225600000	JavaScript Date, Java epoch millis, .NET Unix milliseconds
Microseconds	1767225600000000	some database exports and event pipelines
Nanoseconds	1767225600000000000	tracing systems and high-resolution telemetry

Make the unit visible in field names:

year_start_seconds
year_start_ms
event_time_us
trace_time_ns

Avoid a bare field named timestamp when a codebase mixes seconds and milliseconds.

SQL ranges: use 1767225600 as the lower bound

For all UTC events in 2026, use a half-open range: start inclusive, end exclusive.

Epoch seconds column

SELECT *
FROM events
WHERE event_ts_seconds >= 1767225600
  AND event_ts_seconds <  1798761600;

Epoch milliseconds column

SELECT *
FROM events
WHERE event_ts_ms >= 1767225600000
  AND event_ts_ms <  1798761600000;

PostgreSQL timestamp column

SELECT *
FROM events
WHERE event_time >= TIMESTAMPTZ '2026-01-01 00:00:00+00'
  AND event_time <  TIMESTAMPTZ '2027-01-01 00:00:00+00';

Do not mix units:

-- Wrong: comparing a millisecond column to a seconds boundary
WHERE event_ts_ms >= 1767225600

That bug usually makes the filter include the wrong decade of data.

JavaScript, Python, shell, and SQL checks

Use a runtime check before pasting a year boundary into production code.

JavaScript

Date.UTC() returns milliseconds, so divide by 1000 for Unix seconds:

const start2026Seconds = Date.UTC(2026, 0, 1) / 1000;
const start2026Ms = Date.UTC(2026, 0, 1);

console.log(start2026Seconds);
// 1767225600

console.log(new Date(start2026Ms).toISOString());
// 2026-01-01T00:00:00.000Z

The month index is zero-based: 0 means January.

Python

Use an aware UTC datetime:

from datetime import datetime, timezone

start_2026 = datetime(2026, 1, 1, tzinfo=timezone.utc)

print(int(start_2026.timestamp()))
# 1767225600

Avoid naive datetimes when the boundary is meant to be UTC:

# Risky if the host machine is not set to UTC
datetime(2026, 1, 1).timestamp()

macOS / BSD shell

date -u -j -f '%Y-%m-%d %H:%M:%S' '2026-01-01 00:00:00' +%s
# 1767225600

date -u -r 1767225600 '+%Y-%m-%dT%H:%M:%SZ'
# 2026-01-01T00:00:00Z

Linux / GNU date

date -u -d '2026-01-01 00:00:00' +%s
# 1767225600

date -u -d @1767225600 '+%Y-%m-%dT%H:%M:%SZ'
# 2026-01-01T00:00:00Z

SQLite

SELECT datetime(1767225600, 'unixepoch');
-- 2026-01-01 00:00:00

UTC boundary vs local start of 2026

1767225600 is midnight in UTC. The same instant appears as a different wall-clock time elsewhere.

Timezone display	Local time at Unix 1767225600
UTC	2026-01-01 00:00:00
America/New_York	2025-12-31 19:00:00
America/Los_Angeles	2025-12-31 16:00:00
Europe/London	2026-01-01 00:00:00
Asia/Shanghai	2026-01-01 08:00:00
Asia/Tokyo	2026-01-01 09:00:00

That table answers "what does 1767225600 look like locally?"

A different question is: "what is the Unix timestamp for local midnight at the start of 2026?" Those values are different:

Reporting timezone	Local boundary	UTC instant	Unix seconds
UTC	2026-01-01 00:00:00	2026-01-01 00:00:00Z	1767225600
America/New_York	2026-01-01 00:00:00	2026-01-01 05:00:00Z	1767243600
America/Los_Angeles	2026-01-01 00:00:00	2026-01-01 08:00:00Z	1767254400
Europe/London	2026-01-01 00:00:00	2026-01-01 00:00:00Z	1767225600
Asia/Shanghai	2026-01-01 00:00:00	2025-12-31 16:00:00Z	1767196800
Asia/Tokyo	2026-01-01 00:00:00	2025-12-31 15:00:00Z	1767193200

If your dashboard says "2026 revenue in New York time", the lower bound is 1767243600, not 1767225600.

Use an IANA timezone name such as America/New_York, not a hard-coded offset. Offsets change with daylight-saving rules and political timezone changes.

Computing year-start timestamps safely

Do not compute year starts by adding 365 * 86400 to the previous boundary. Leap years eventually break that shortcut.

Use a date library:

function utcYearStartSeconds(year) {
  return Date.UTC(year, 0, 1) / 1000;
}

console.log(utcYearStartSeconds(2026));
// 1767225600

Python:

def utc_year_start_seconds(year: int) -> int:
    return int(datetime(year, 1, 1, tzinfo=timezone.utc).timestamp())

Useful nearby UTC boundaries:

Boundary	Unix seconds	UTC time
Start of 2025	1735689600	2025-01-01 00:00:00 UTC
Start of 2026	1767225600	2026-01-01 00:00:00 UTC
End of 2026 / start of 2027	1798761600	2027-01-01 00:00:00 UTC
Last whole second of 2026	1798761599	2026-12-31 23:59:59 UTC

2026 is not a leap year:

1798761600 - 1767225600 = 31536000
31536000 = 365 * 86400

Common mistakes with 1767225600

Treating seconds as milliseconds

JavaScript Date expects milliseconds:

new Date(1767225600).toISOString();
// 1970-01-21T10:53:45.600Z  <-- wrong unit

new Date(1767225600 * 1000).toISOString();
// 2026-01-01T00:00:00.000Z

Using UTC when the report is local

UTC year boundaries are correct for logs, APIs, and global event tables. Local business reports may need a local-year boundary first. Compute local midnight in the report timezone, then convert to UTC.

Writing inclusive end-of-year filters

This is fragile for fractional seconds:

WHERE event_time BETWEEN 1767225600 AND 1798761599

This is safer:

WHERE event_time >= 1767225600
  AND event_time <  1798761600

Hiding the unit in variable names

Prefer:

start_of_2026_seconds
startOf2026Ms

Avoid:

timestamp
start

Copy-paste checklist

Before shipping 1767225600, check:

1. The boundary is meant to be UTC, not a local business timezone.
2. The receiving system expects seconds, not milliseconds.
3. A 13-digit version is used for JavaScript Date and millisecond columns.
4. The 2026 range uses < 1798761600 as the upper bound.
5. Test data includes one row before 1767225600, one exactly at it, and one exactly at 1798761600.
6. Human-facing docs include the ISO string 2026-01-01T00:00:00Z beside the raw number.

Official references

• MDN Date.UTC - JavaScript UTC date construction returns milliseconds since the Unix epoch.
• MDN JavaScript Date - JavaScript Date represents one timestamp value.
• Python datetime timestamp - Python conversion from aware datetimes to Unix timestamps.
• PostgreSQL date/time functions - timestamp comparison, extraction, and timezone-aware date functions.
• IANA Time Zone Database - canonical timezone names and rule data.

Related timestamp guides

• End of 2026 Unix Timestamp: 1798761600 vs 1798761599
• Start of 2027 Unix Timestamp: 1798761600
• Unix Timestamps for 2026 - every month
• Unix Time to Date: Convert Epoch to Time
• Date to Epoch: Time to Unix Timestamp
• 10 Common Unix Timestamp Bugs