Time & Date

Understanding Dates & Time: Timestamps, Time Zones, Formats & Date Math

Why dates and time are deceptively hard — how computers count time as a single number, why time zones and daylight saving complicate everything, the standard formats, and why date arithmetic is full of traps.

Dates and time look simple and are notoriously hard — there is a running joke among programmers that every assumption you make about time is wrong. Time zones shift, clocks jump forward and back, months vary in length, years occasionally gain a day, and two countries write the same date differently. This guide untangles the four sources of that difficulty and links to a deeper article on each.

Every concept pairs with a tool that runs in your browser, starting with the Unix Timestamp Converter and Timezone Converter.

How computers count time

Underneath all the complexity, computers keep time with a single number: the count of seconds since a fixed instant. The most common reference is the Unix epoch — midnight UTC on 1 January 1970. Right now is just some large number of seconds since then. This is brilliant because it makes a moment in time unambiguous and easy to compare: a bigger number is later, and the gap between two events is simple subtraction.

This single-number representation is the Unix timestamp, and it is how databases, log files and APIs store time internally. Its mechanics — and the famous “Year 2038 problem” — are in Unix Timestamps Explained.

💡The golden rule of handling time: store an absolute moment, display a local one. Keep a timestamp or a UTC time internally; convert to the user’s time zone only when you show it. Almost every date bug comes from storing local times without their zone.

The complication: time zones and DST

A single number is clean — until you have to show it to a human, who experiences time in their local zone. The world is divided into time zones, each defined as an offset from UTC (Coordinated Universal Time), the global reference clock. New York is UTC−5, India is UTC+5:30, and the same instant is “3pm” in one place and “midnight” in another.

Worse, many regions observe daylight saving time, shifting their offset by an hour twice a year — so a zone’s offset is not even constant. This is why “what time is it there?” is a genuinely hard computation, covered in Time Zones & UTC Explained.

The confusion: date formats

Even writing a date is contested. 06/12/2026 is June 12th in the US and December 6th almost everywhere else — a genuine source of errors. The fix is a single international standard, ISO 8601 (2026-06-12, always year-month-day), which is unambiguous and sorts correctly as text. Why it wins and how to read its full timestamp form is in ISO 8601 Explained.

⚠️Format is presentation; time zone is meaning. 2026-06-12 and 12 June 2026 are the same date written two ways. But “3pm” in Tokyo and “3pm” in London are different moments. Never confuse how a time is written with which clock it refers to.

The traps: date arithmetic

“Add one month to January 31st” — to what? “How many days until a date?” sounds trivial but has to account for leap years, month lengths and DST transitions (some days are 23 or 25 hours long). “How many business days?” means skipping weekends and holidays. Date arithmetic is full of edge cases that catch even experienced developers, which is why dedicated tools and libraries exist. The common pitfalls are in Date & Time Math.

Putting it together

So a single timestamp moves through several layers before a person reads it: the computer stores an absolute Unix timestamp (or UTC), a time zone converts it to the right local clock, an ISO 8601 or localised format writes it out, and any date math carefully accounts for the calendar’s irregularities. Get the layering right — absolute internally, local for display — and most time bugs simply never happen.

In practice

Time is hard because human calendars are irregular and the world keeps many clocks at once; computers tame it by counting one number and converting only at the edges. Explore each layer in the linked articles, and convert timestamps, zones and formats with the Unix Timestamp and Timezone tools — all in your browser.

Frequently asked questions

Why is working with dates and time so hard?

Because human timekeeping is messy: time zones, daylight saving time, leap years, leap seconds, months of different lengths, and competing date formats all collide. Computers simplify it by counting a single number (seconds since a fixed moment), but converting that to and from human local time is where the difficulty lives.

What is the best way to store a date and time?

Store an absolute moment — typically a Unix timestamp or an ISO-8601 string in UTC — not a local time. Convert to the user's time zone only for display. Storing local times without their zone is the root of countless bugs.

What is UTC?

UTC (Coordinated Universal Time) is the global time standard that every time zone is defined as an offset from. It does not observe daylight saving and never changes, which makes it the reliable reference for storing and comparing moments in time.

What is the difference between a date format and a time zone?

A format is how a date is written (e.g. 2026-06-12 vs 06/12/2026) — purely presentation. A time zone is which local clock the time refers to. The same moment can be written in many formats and shown in many zones; they are independent concerns.

Was this article helpful?