Question 1

Why do some APIs return milliseconds and others return seconds?

Accepted Answer

The Unix timestamp standard (POSIX.1-2017 §4.16) defines 'Seconds Since the Epoch' in seconds — not milliseconds. The original Unix operating system was written in the late 1960s on machines where counting in milliseconds would have overflowed the available integer sizes quickly. Seconds were sufficient for the epoch timescales being modeled. The milliseconds convention originates primarily from JavaScript: the ECMAScript specification defines Date.now() to return the number of milliseconds elapsed since the Unix epoch. This decision was made because JavaScript runs in browser environments where millisecond precision is needed for animation timing, performance measurement (performance.now()), and input event handling — all sub-second operations. Many modern web APIs and platforms follow JavaScript's convention and return milliseconds for consistency with frontend code. The practical consequence: if you receive a timestamp value of 1,716,000,000, it is in seconds (representing May 18, 2024 at approximately 04:00 UTC). If you receive 1,716,000,000,000, it is in milliseconds (representing the same date). The rule of thumb: if the timestamp has 13 or more digits, it is almost certainly milliseconds. If it has 10 digits, it is seconds. Values greater than 10¹² are unambiguously milliseconds in any system where the Unix epoch started in 1970 — no second-resolution timestamp will reach 10¹² until November 20, 33658 AD.

Question 2

What is the Unix epoch and why does it start in 1970?

Accepted Answer

The Unix epoch — January 1, 1970 at 00:00:00 UTC — is the reference point from which Unix timestamps are measured. The choice of 1970 was pragmatic: it was selected during Unix development at Bell Labs in the late 1960s as a convenient recent date that could be represented in the available integer types on the PDP-11 minicomputers being used. Brian Kernighan and Dennis Ritchie have noted in various interviews that the specific date was not deeply reasoned — it was simply a round date within the range of 32-bit integers that allowed for both historical timestamps (negative values, representing dates before 1970) and future timestamps. The epoch 0 = 1970-01-01T00:00:00Z is now a global standard codified in POSIX.1-2017 §4.16: 'The number of seconds elapsed since the Epoch, excluding leap seconds.' The 'excluding leap seconds' clause is significant (see the leap second FAQ below). Alternative epoch choices that were considered historically: January 1, 1900 (used by NTP, Windows FILETIME offset, and some IBM systems), January 1, 1904 (used by older Macintosh systems), January 1, 2000 (GPS time, used by some embedded systems). The 1970 epoch won by virtue of becoming the Unix standard — and Unix's dominance in operating systems made it the de facto global convention.

Question 3

What happens in 2038 with 32-bit timestamps?

Accepted Answer

The Y2K38 problem (also called the Year 2038 problem, Unix Year 2038 problem, or Time Overflow) occurs because signed 32-bit integers can represent values from −2,147,483,648 to 2,147,483,647. As a Unix timestamp, 2,147,483,647 seconds after the epoch corresponds to 2038-01-19T03:14:07Z. The next second — 2,147,483,648 seconds after the epoch — overflows a signed 32-bit integer to −2,147,483,648, which as a timestamp represents December 13, 1901, at 20:45:52 UTC. Systems that store Unix timestamps in signed 32-bit columns (time_t on 32-bit Linux systems, many older database integer types) will roll over to this negative value, potentially causing date display errors, sort order failures, and logic bugs in date arithmetic. The fix is straightforward on modern systems: use 64-bit timestamps. A signed 64-bit Unix timestamp can represent dates up to approximately 292 billion years from now (292,277,026,596 years to be precise), which is a sufficient planning horizon. Most modern systems already use 64-bit time_t on 64-bit operating systems. Remaining risk areas: embedded systems running 32-bit OS kernels, legacy database integer columns defined as INT (32-bit) rather than BIGINT (64-bit), and file system timestamps in older formats. MySQL TIMESTAMP columns are 32-bit and are affected; DATETIME columns are not. PostgreSQL TIMESTAMP columns use 64-bit storage and are not affected.

Question 4

What's the difference between UTC and GMT?

Accepted Answer

UTC (Coordinated Universal Time) and GMT (Greenwich Mean Time) refer to different things, though they show the same time for most practical purposes. GMT is a timezone based on the position of the sun over the Royal Observatory in Greenwich, London. It was the international time standard before 1972. UTC replaced GMT as the global time standard in 1972. UTC is defined by atomic clocks (specifically, International Atomic Time, TAI) with the addition of leap seconds to keep UTC within 0.9 seconds of the Earth's actual rotation (Universal Time 1, UT1). GMT was astronomical time — defined by the Earth's rotation — and varied slightly due to the Earth's non-uniform rotation. UTC is atomic time — highly precise and uniform — adjusted for the Earth's rotation via leap seconds. In practice: for software timestamps, UTC and GMT show the same hour and minute. The difference matters only for very high-precision timing (nanosecond-level) or leap second handling. When you see 'UTC' in an ISO 8601 timestamp (the Z suffix or +00:00 offset), it means the time is given relative to the UTC reference point. When you see 'GMT' in an older HTTP Date header (e.g., 'Date: Mon, 01 Jan 2024 00:00:00 GMT'), it also means UTC offset 0 by convention. For software development: always say UTC and store UTC, not GMT — UTC is the current international standard per POSIX and ISO 8601.

Question 5

How do I convert a Unix timestamp to a specific timezone in JavaScript?

Accepted Answer

The standard approach in modern JavaScript uses the Intl.DateTimeFormat API with a timeZone option. Given a Unix timestamp in seconds (e.g., 1716000000), convert to milliseconds first, then use Intl: `new Intl.DateTimeFormat('en-US', { timeZone: 'America/Chicago', dateStyle: 'full', timeStyle: 'long' }).format(new Date(1716000000 * 1000))`. The timeZone option accepts IANA timezone names from the IANA Time Zone Database (e.g., 'America/Chicago', 'Europe/Berlin', 'Asia/Tokyo', 'Australia/Sydney') — not abbreviations like 'CST' or 'EST' (which are ambiguous: CST could be Central Standard Time USA or China Standard Time). The Intl API handles Daylight Saving Time transitions automatically using the IANA database bundled with the JavaScript runtime. For Node.js applications: the temporal-polyfill package and the TC39 Temporal API (Stage 3 proposal as of 2026) provide a more ergonomic API: `Temporal.Instant.fromEpochSeconds(1716000000).toZonedDateTimeISO('America/Chicago').toString()`. For server-side timestamp handling where timezone display is not needed: always normalize to UTC and store as UTC Unix seconds in your database — never store timestamps in local time.

Question 6

What's ISO 8601 and when should I use it instead of Unix timestamps?

Accepted Answer

ISO 8601:2004 is the international standard for representing date and time. The canonical format is `YYYY-MM-DDTHH:mm:ss.sssZ` for UTC (the Z suffix means +00:00 offset) or `YYYY-MM-DDTHH:mm:ss±HH:mm` for a specific UTC offset. Examples: `2026-05-23T15:30:00Z` (2:30pm UTC on May 23, 2026); `2026-05-23T10:30:00-05:00` (10:30am in UTC-5, which is the same moment). ISO 8601 is human-readable, self-documenting, and sorts lexicographically (alphabetical sort = chronological sort when stored as strings in UTC). Unix timestamps (seconds since 1970-01-01T00:00:00Z) are compact, arithmetic-friendly, and timezone-agnostic but not human-readable. Use Unix timestamps when: doing arithmetic on times (adding/subtracting durations, comparing timestamps); storing timestamps in databases where storage efficiency matters; passing timestamps between systems where timezone interpretation is a source of bugs (Unix timestamps are always UTC). Use ISO 8601 when: displaying timestamps to humans in logs, emails, or UIs; storing timestamps in formats where humans will read the raw data (config files, JSON APIs consumed by humans, error messages); complying with RFC 3339 (which is a profile of ISO 8601 used in internet protocols like HTTP, RSS, Atom, OpenAPI 3.x). Note: RFC 3339 is a strict subset of ISO 8601 that requires the T separator (not a space), mandates including seconds, and prohibits certain ISO 8601 options. Most API standards (OpenAPI 3.x, JSON:API, RFC 7231 for HTTP) reference RFC 3339 specifically.

Question 7

How do I handle daylight saving time in timestamp conversions?

Accepted Answer

The short answer: don't convert to local time until you must display to a user. Store everything in UTC Unix timestamps or ISO 8601 with Z suffix. The longer answer: Daylight Saving Time (DST) is a policy applied by governments, not a property of time itself. When DST transitions happen, wall-clock times become ambiguous (in fall, the hour between 1:00am and 2:00am occurs twice) or non-existent (in spring, the hour between 2:00am and 3:00am doesn't exist). UTC has no DST — it is continuous and monotonic. UTC Unix timestamps are unambiguous: 1,716,000,000 is a single specific moment regardless of what timezone it's displayed in. The moment of transition is a single UTC second. DST transitions are encoded in the IANA Time Zone Database (tzdata, shipped with Linux, macOS, and modern JavaScript runtimes) as historical data per timezone. When you convert a UTC timestamp to a local timezone using the IANA database (e.g., via Intl.DateTimeFormat or Java's java.time package), the DST rules for that timezone at that specific date are applied automatically. The common mistake: using timezone abbreviations like 'EST' as if they are stable. EST is UTC-5 (no DST), but 'Eastern Time' is either EST (UTC-5, winter) or EDT (UTC-4, summer) — and the transition date changes. Use IANA timezone names (America/New_York) rather than abbreviations (EST/EDT) to avoid ambiguity. Cron job scheduling recommendation: always schedule in UTC and document the local-time equivalent. 'Runs at 9am ET' is ambiguous twice a year. 'Runs at 14:00 UTC (9am ET in winter, 10am ET in summer)' is unambiguous.

Question 8

Why does JavaScript's Date.parse() behave differently across browsers?

Accepted Answer

Date.parse() is notoriously inconsistent across browsers because the ECMAScript specification historically left many date string formats undefined or implementation-dependent. The ECMAScript 2024 specification (Section 21.4.3.2) defines a specific subset of ISO 8601 that Date.parse() MUST handle: date-only strings (YYYY, YYYY-MM, YYYY-MM-DD) and combined date-time strings (YYYY-MM-DDTHH:mm:ss.sssZ). Strings matching this subset should behave consistently across V8 (Chrome/Node), SpiderMonkey (Firefox), and JavaScriptCore (Safari). The inconsistencies appear with: (1) Date-only strings without time: 'YYYY-MM-DD' is treated as UTC midnight in modern browsers but was historically treated as local midnight in some older browsers — always append T00:00:00Z explicitly. (2) Non-ISO 8601 formats: 'May 23, 2026' or '05/23/2026' are parsed by browser-specific heuristics and differ across browsers and locales — never rely on these. (3) ISO 8601 strings with timezone offsets: 'YYYY-MM-DDTHH:mm:ss+05:30' (IST) should work per spec but had Safari bugs pre-2021. Best practice: for any JavaScript date parsing that must work consistently: always use ISO 8601 format with explicit timezone (Z or ±HH:mm), or parse the Unix timestamp directly via `new Date(unixTimestampMs)` — the millisecond constructor is unambiguous in all environments. The Temporal API (TC39 Stage 3) addresses these inconsistencies with a new API that strictly follows ISO 8601 and requires explicit timezone specification.

Unix Timestamp Converter

Inputs coming in next batch

Frequently asked questions