All developer date tools

Timestamps

Units, and the bug they cause

The same instant can be written in seconds, milliseconds, microseconds or nanoseconds. Reading one as another is probably the most common date bug in production code, and it fails loudly in one direction and silently in the other: a milliseconds value read as seconds lands in the year 57000, while a seconds value read as milliseconds lands in January 1970.

For dates in the current era, count the digits:

Digits Unit Typical sources
10 Seconds Unix, PHP time(), most REST APIs, JWT exp
13 Milliseconds JavaScript Date.now(), Java currentTimeMillis()
16 Microseconds Python datetime, PostgreSQL, Chrome traces
19 Nanoseconds Go UnixNano(), InfluxDB, Prometheus internals

The timestamp converter detects the unit by magnitude and always reports which one it used, so an ambiguous number cannot produce a confidently wrong date.

Timestamps have no time zone

A timestamp identifies one instant, identically everywhere. A time zone is applied only when you display it. Storing a "local timestamp" is almost always a mistake: store the instant, store the zone separately if you need to know where the event happened, and convert at the point of display.

ISO 8601 in practice

2026-07-30T14:30:00+01:00 is unambiguous and sorts correctly as a string. A few points that catch people out:

  • Z means UTC, and is equivalent to +00:00. It does not mean "no time zone".
  • A string with no offset at all is a local time with no defined instant. Different parsers treat it differently — some assume UTC, some assume system local.
  • Week dates such as 2026-W31-4 are valid ISO 8601 and use the ISO week rules described on the week number calculator.

Boundaries worth testing against

  • 0 — the epoch, 1 January 1970 UTC. Frequently appears as an accidental default when a null date is coerced to a number.
  • 2147483647 — 19 January 2038, the signed 32-bit limit. Anything storing time in 32 bits wraps to 1901 past this point.
  • Negative values — dates before 1970. Handled inconsistently across languages and databases, so worth an explicit test.
  • Daylight-saving boundaries — the skipped hour and the repeated hour. Both are covered by the time zone converter.

Leap seconds

Unix time ignores them, treating every day as exactly 86,400 seconds. It is therefore not a true count of elapsed SI seconds since 1970 — which is precisely the compromise that makes the arithmetic tractable.

Other categories