1798761600 is the half-open end of 2026
The Unix timestamp 1798761600 equals 2027-01-01T00:00:00.000Z — the first instant after 2026 ends. In range queries (SQL, log filters, time-series indexes) this is the correct upper bound: it includes every event with a timestamp strictly less than it. The same value is the start of 2027, so you can think of it as the boundary line itself rather than a side.
1798761599 is the last whole second of 2026
If you specifically need a value still inside 2026, subtract one: 1798761599 = 2026-12-31T23:59:59.000Z. This is the right form for inclusive endpoints (BETWEEN ... AND 1798761599 in SQL, or labelling "the final second of 2026"). It loses any event that happens between 23:59:59.000 and 24:00:00.000, so prefer the half-open 1798761600 boundary for anything that stores fractional seconds.
- Inclusive endpoint: 1798761599 = 2026-12-31 23:59:59 UTC
- Half-open boundary: 1798761600 = 2027-01-01 00:00:00 UTC
- Difference: 1 second
- Use half-open in WHERE event_time < 1798761600 (correct at any precision)
- Use inclusive in WHERE event_time BETWEEN ... AND 1798761599 (loses ms events)
Seconds and milliseconds forms
Most APIs return Unix seconds, but JavaScript Date, Java Instant, and many time-series databases store milliseconds. Multiply by 1000 for the millisecond form.
- Unix seconds (exclusive end): 1798761600
- Unix milliseconds (exclusive end): 1798761600000
- Unix seconds (inclusive last sec): 1798761599
- ISO 8601 UTC: 2027-01-01T00:00:00.000Z
- JavaScript: new Date(1798761600 * 1000).toISOString()
- Linux: date -u -d @1798761600
Local timezone notes
Year boundaries are defined here in UTC. In timezones west of UTC, the timestamp 1798761600 still falls on December 31, 2026 in local wall-clock time. Fiscal-year and analytics dashboards that bin events by local day should compute the boundary in their reporting timezone — not in UTC.
- UTC: 2027-01-01 00:00:00 (year boundary)
- America/New_York (EST, UTC−5): 2026-12-31 19:00:00 — still 2026 locally
- America/Los_Angeles (PST, UTC−8): 2026-12-31 16:00:00 — still 2026 locally
- Europe/London (GMT, UTC+0): 2027-01-01 00:00:00 — matches UTC
- Asia/Tokyo (JST, UTC+9): 2027-01-01 09:00:00 — already 2027 locally
- Asia/Shanghai (CST, UTC+8): 2027-01-01 08:00:00 — already 2027 locally
Range queries: half-open is the safe default
Most production code uses the half-open boundary because it works at any precision. Use the inclusive form only when the contract explicitly says "the last second of 2026" (display labels, report titles).
- JavaScript: events.filter(e => e.ts < 1798761600)
- Python: [e for e in events if e.ts < 1798761600]
- SQL: WHERE event_time >= 1767225600 AND event_time < 1798761600 -- all of 2026
- Postgres timestamptz: WHERE event_time < '2027-01-01 00:00:00+00'
- Influx / range scans: 1767225600..1798761600
How to compute the end of any year in code
The end of any year in UTC — in the half-open sense — is the start of the next year. Let a date library do the math so you handle leap years correctly. 2028 is a leap year and has 366 days; the 2027 → 2028 boundary is 1830297600.
- JavaScript: Date.UTC(2027, 0, 1) / 1000 = 1798761600 // half-open end of 2026
- JavaScript: Date.UTC(2027, 0, 1) / 1000 - 1 = 1798761599 // inclusive last sec
- Python: int(datetime(2027, 1, 1, tzinfo=timezone.utc).timestamp())
- Linux: date -u -d '2027-01-01' +%s
- Start of 2026 in UTC: 1767225600 (use as inclusive lower bound)
- End of 2027 / start of 2028 in UTC: 1830297600
FAQ
- What is the Unix timestamp for the end of 2026?
- It depends on what you mean. The first instant outside 2026 is 1798761600 (2027-01-01 00:00:00 UTC); use this as an exclusive upper bound in range queries. The last whole second still inside 2026 is 1798761599 (2026-12-31 23:59:59 UTC); use this when you need an inclusive endpoint at second precision.
- Should I use 1798761599 or 1798761600 in a SQL WHERE clause?
- Use 1798761600 with a strict less-than: WHERE event_time < 1798761600. The half-open form is correct whether your column stores seconds, milliseconds, or microseconds. The inclusive form (BETWEEN ... AND 1798761599) silently drops fractional-second events on 2026-12-31.
- What is the difference between 1798761600 and the start of 2027?
- They are the same instant. 1798761600 is both the end of 2026 (exclusive) and the start of 2027 (inclusive). UTC year boundaries are points in time, not intervals.
- How do I compute the end of any year in JavaScript?
- Use Date.UTC(year + 1, 0, 1) / 1000 for the exclusive upper bound, or subtract 1 for the inclusive last second: Date.UTC(year + 1, 0, 1) / 1000 - 1.