Start of 2027 Unix Timestamp: 1798761600 (UTC)

Quick answer

1798761600 is the Unix timestamp for:

2027-01-01T00:00:00.000Z

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

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

For a full-year 2027 UTC query, use:

WHERE event_time >= 1798761600
  AND event_time <  1830297600

For a full-year 2026 UTC query, the same 1798761600 value is the end boundary:

WHERE event_time >= 1767225600
  AND event_time <  1798761600

What 1798761600 means

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

This number is useful in two common ways:

• as the inclusive UTC lower bound for 2027,
• as the exclusive UTC upper bound for 2026.

That dual meaning is why the value appears in both "start of 2027" and "end of 2026" searches.

In production code, the safest wording is:

1798761600 is the UTC boundary between 2026 and 2027.

Then decide which side of the boundary your query should include.

Seconds, milliseconds, microseconds, and nanoseconds

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

Unit	Start of 2027 value	Typical use
Seconds	1798761600	Unix tools, many APIs, JWT-style claims, SQL epoch values
Milliseconds	1798761600000	JavaScript Date, Java epoch millis, .NET Unix milliseconds
Microseconds	1798761600000000	some database exports and event pipelines
Nanoseconds	1798761600000000000	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 for 2027 and 2026

For UTC calendar-year filters, use half-open ranges: start inclusive, end exclusive.

All UTC events in 2027

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

All UTC events in 2026

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

Millisecond column

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

PostgreSQL timestamp column

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

Do not write a 2027 range as:

WHERE event_time BETWEEN 1798761600 AND 1830297599

That form is fragile for fractional seconds. A row at 2027-12-31T23:59:59.500Z can be missed if the endpoint is only the last whole second.

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 start2027Seconds = Date.UTC(2027, 0, 1) / 1000;
const start2027Ms = Date.UTC(2027, 0, 1);

console.log(start2027Seconds);
// 1798761600

console.log(new Date(start2027Ms).toISOString());
// 2027-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_2027 = datetime(2027, 1, 1, tzinfo=timezone.utc)

print(int(start_2027.timestamp()))
# 1798761600

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

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

macOS / BSD shell

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

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

Linux / GNU date

date -u -d '2027-01-01 00:00:00' +%s
# 1798761600

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

SQLite

SELECT datetime(1798761600, 'unixepoch');
-- 2027-01-01 00:00:00

UTC boundary vs local start of 2027

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

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

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

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

Reporting timezone	Local boundary	UTC instant	Unix seconds
UTC	2027-01-01 00:00:00	2027-01-01 00:00:00Z	1798761600
America/New_York	2027-01-01 00:00:00	2027-01-01 05:00:00Z	1798779600
America/Los_Angeles	2027-01-01 00:00:00	2027-01-01 08:00:00Z	1798790400
Europe/London	2027-01-01 00:00:00	2027-01-01 00:00:00Z	1798761600
Asia/Shanghai	2027-01-01 00:00:00	2026-12-31 16:00:00Z	1798732800
Asia/Tokyo	2027-01-01 00:00:00	2026-12-31 15:00:00Z	1798729200

If your dashboard says "2027 revenue in New York time", the lower bound is 1798779600, not 1798761600.

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(2027));
// 1798761600

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 2026	1767225600	2026-01-01 00:00:00 UTC
End of 2026 / start of 2027	1798761600	2027-01-01 00:00:00 UTC
End of 2027 / start of 2028	1830297600	2028-01-01 00:00:00 UTC
Last whole second of 2027	1830297599	2027-12-31 23:59:59 UTC

2027 is not a leap year:

1830297600 - 1798761600 = 31536000
31536000 = 365 * 86400

2028 is a leap year, so the next year has a longer range. That is why date libraries are safer than adding a fixed number of seconds forever.

Common mistakes with 1798761600

Treating seconds as milliseconds

JavaScript Date expects milliseconds:

new Date(1798761600).toISOString();
// 1970-01-21T19:39:21.600Z  <-- wrong unit

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

Forgetting that it is also the end of 2026

If a bug report says "end of 2026 timestamp", check whether the code wants:

• 1798761600 as the exclusive upper bound, or
• 1798761599 as the last whole second inside 2026.

For ranges, prefer the exclusive boundary.

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.

Hiding the unit in variable names

Prefer:

start_of_2027_seconds
startOf2027Ms

Avoid:

timestamp
start

Copy-paste checklist

Before shipping 1798761600, 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. A 2027 range uses < 1830297600 as the upper bound.
5. A 2026 range uses < 1798761600 as the upper bound.
6. Test data includes one row before 1798761600, one exactly at it, and one exactly at 1830297600.
7. Human-facing docs include the ISO string 2027-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 2026 Unix Timestamp: 1767225600
• Unix Timestamps for 2027 - every month
• Unix Time to Date: Convert Epoch to Time
• Date to Epoch: Time to Unix Timestamp
• 10 Common Unix Timestamp Bugs