Unix time conversion
Convert integer Unix time in seconds to a civil date/time, or interpret a local civil time in a named IANA time zone and obtain its Unix timestamp.
What is a Unix timestamp?
Unix time represents an instant using an integer count relative to the Unix Epoch, 1970-01-01 00:00:00 UTC. The familiar timestamp 0 therefore corresponds to the epoch itself. Positive values represent later instants and, on systems that support them, negative values represent instants before the epoch.
A Unix timestamp does not carry a local time zone
The timestamp identifies an instant independently of whether it is later displayed in São Paulo, New York, London or Tokyo. A time zone is applied when that instant is converted into civil calendar fields such as year, month, day, hour and UTC offset. This is why one timestamp can produce different local clock readings without representing different instants.
Why use America/Sao_Paulo instead of only UTC−03:00?
An IANA time-zone identifier refers to a rule history rather than only a fixed numeric offset. The IANA Time Zone Database records civil-time transitions and is periodically updated when governments change time-zone boundaries or daylight-saving rules. A fixed offset such as UTC−03:00 contains no historical or future transition rules.
UTC, UTC offset and time zone are different concepts
UTC is the reference time scale used for civil-time coordination. An offset such as −03:00 describes a displacement from UTC at a particular instant. A named zone such as America/Sao_Paulo represents a set of civil-time rules that can map different historical instants to different offsets. Treating these three concepts as interchangeable is a common source of date/time bugs.
Timestamp Unix versus a textual Internet date/time
A Unix timestamp is compact and convenient for computation, while ISO 8601-style representations are human-readable and can explicitly include an offset. RFC 3339 defines an Internet date/time profile based on ISO 8601 conventions. An output such as 2026-08-30T11:00:00-03:00 communicates calendar fields and the numeric offset, while the Unix timestamp communicates the instant as a numeric epoch-based value.
Daylight-saving transitions can create missing or repeated local times
When a civil clock moves forward, some local wall-clock times can be skipped. When it moves backward, some local times can occur twice with different UTC offsets. This makes “local date/time → instant” inherently more complicated than “timestamp → local date/time”. For critical scheduling systems, store an instant plus the intended IANA zone and define how ambiguous or nonexistent local times must be handled.
Unix/POSIX time is not a leap-second counter
The conventional POSIX/Unix model used by typical operating systems and PHP does not represent leap seconds as extra distinct timestamp values in the ordinary time scale. This matters when comparing Unix timestamps with specialized astronomical or precision time scales. For normal web, server, logging and application work, use the platform Unix-time semantics consistently.
The Year 2038 problem depends on the platform integer/time representation
A signed 32-bit time representation reaches its positive limit at 2038-01-19 03:14:07 UTC. Modern 64-bit environments provide a vastly larger range, but software interoperability still requires attention when exchanging timestamps with legacy databases, devices, protocols or 32-bit systems. This calculator validates input against the integer range available to the running PHP environment.
10-digit and 13-digit values are often different timestamp units
Traditional Unix timestamps used by this calculator are expressed in seconds. Many JavaScript and API environments also use milliseconds since the epoch, which currently produces values with roughly 13 decimal digits instead of the familiar roughly 10-digit second timestamps. Always confirm the unit before converting or storing an epoch value.
Store instants and civil-time intent deliberately
For events that already happened, storing an unambiguous instant is usually essential. For future civil schedules — for example, “09:00 every Monday in São Paulo” — the named time zone can also be part of the business meaning because governments can change civil-time rules. Converting every future schedule permanently to a fixed UTC offset can lose that intent.