Today’s date in numbers and every format

ISO 8601 at a glance

ISO 8601 is the international standard for writing dates and times as numbers. Its current version is in two parts, ISO 8601-1:2019 (basic rules) and ISO 8601-2:2019 (extensions), with amendments in 2022 and 2025. The idea is simple: write the largest unit first and pad every field to a fixed width, so dates sort correctly as text and read the same in every language. The forms you will meet, with today’s values:

The week date counts Monday as day 1 and Sunday as day 7. Week 1 is the week with the year’s first Thursday, so the week-numbering year can differ from the calendar year for a few days around January 1: January 1, 2027 is 2026-W53-5. The ordinal date counts the days of the year from 001 to 365 or 366. It is the format behind the five-digit “Julian dates” of logistics and the military (YYDDD, such as 26307 today), which have nothing to do with the astronomers’ Julian Day. The offset is local time minus UTC, so 14:39-05:00 and 19:39Z are the same instant. RFC 3339 writes offsets in hours and minutes, and RFC 9557 notes that ISO 8601 does not allow −00:00.

Internet formats: RFC 3339, email and HTTP

RFC 3339 is the profile of ISO 8601 used by most internet protocols and APIs. It requires a full date, a time and an offset (1985-04-12T23:20:50.52Z). It allows a space instead of the T, and it rules out the hour 24, week dates and ordinal dates. RFC 9557 (2024) extends it with a time zone name in brackets, 2026-11-02T14:39:07-05:00[America/New_York]. That matters because an offset alone does not say which rules apply after the next daylight saving change.

Email headers use the RFC 5322 format, Mon, 02 Nov 2026 14:39:07 -0500, with an English weekday and month abbreviation and an offset without a colon. Old messages may carry two-digit years. The standard reads 00–49 as 2000–2049 and 50–99 as 1950–1999. HTTP headers use the IMF-fixdate of RFC 9110, Sun, 06 Nov 1994 08:49:37 GMT, which is always in UTC even though it says GMT.

Dates as numbers

Computers usually store a moment as a count from a fixed start. Unix time counts seconds since 1970-01-01 00:00:00 UTC and treats every day as 86,400 seconds, ignoring leap seconds. A 10-digit number is seconds and a 13-digit number milliseconds, the JavaScript and Java convention. Mixing the two puts a date in January 1970 or tens of thousands of years ahead. A signed 32-bit count of seconds runs out at 2038-01-19 03:14:07 UTC. Excel counts days in its 1900 date system, where January 1, 1900 is serial 1. Excel also wrongly treats 1900 as a leap year, a Lotus 1-2-3 compatibility choice, so serials from March 1, 1900 on equal the days since December 30, 1899. Workbooks created in the 1904 system, the old Mac default, are 1,462 days off. Julian Day numbers, used in astronomy, count days since noon UT on January 1, 4713 BC in the Julian calendar.

Format codes in software

Every tool has its own letters for the same fields, and several letters mean different things in different tools. This table gives the code for each field in four common systems:

* In Unicode patterns, week fields follow the locale’s week rules; they give ISO weeks only with an ISO locale or ISO week settings. In Excel, mm means minutes when it follows h or precedes s, and months otherwise. Day.js uses Moment’s letters, but week and day-of-year tokens need its plugins.

The mistakes that cause real bugs:

• YYYY instead of yyyy. In Unicode patterns, Y is the week-numbering year. It is the same as the calendar year except for a few days around New Year, so the bug only appears in late December or early January.
• DD instead of dd. In Unicode patterns, D is the day of the year. On February 3 it gives 34, but in January it looks right.
• mm instead of MM. In Unicode and Moment patterns, mm is minutes and MM the month, so a date printed at 14:39 comes out as 2026-39-02.
• hh instead of HH. hh is the 12-hour clock; without an AM/PM field, 14:00 and 02:00 both print as 02.
• A local time without an offset. 2026-11-01 01:30 happened twice in New York, once before and once after the clocks went back. Store UTC or include the offset, and keep the zone name if future times must follow local rules.