Numbers, dates and time zones: say and write them

A release date written 04/03/26 is the fourth of March to a reader in India and the third of April to one in the US: Node.js 24.21.0 formats one instant as 04/03/26 with its Indian English locale data and as 3/4/26 with its US English data. Dates, times and numbers that look exact in one office can name a different moment, or a different amount, in another.

This lesson shows how to write dates nobody can misread and how to give a time with its zone when “IST” alone has two meanings. The parts that follow plan one stand-up through the US and UK clock changes, convert the Indian numbering system for readers abroad, and say versions, IDs and percentages aloud.

Write the month as a word, or the date in ISO 8601 order

Google’s style guide warns that dates written in numbers only “can be confusing”, and gives its own example: in the UK, 04/05/09 means May 4, 2009, and in the US it means April 5, 2009. Its advice is to write the full month name, the day and the four-digit year, as in January 19, 2017, and for dates in numbers only to follow ISO 8601ISO 8601: The international standard for writing dates and times. Its date form runs from the largest unit to the smallest, year, month and day, as YYYY-MM-DD, so it reads one way everywhere.’s year-month-day order, as in 2017-04-15. The W3C’s article on date formats gives the same two remedies: month names with four-digit years, or ISO 8601. Microsoft’s guide adds: “Don’t use numerals to represent months.”

The program formats one instant with the locale data that ships with Node.js, the Unicode CLDR:

// One instant, formatted by the locale data that ships with Node.js (ICU and the Unicode CLDR). The short numeric forms
// disagree with each other; a month written as a word, and ISO 8601's year-month-day, read the same everywhere.

const instant = new Date(Date.UTC(2026, 2, 4, 9, 30)); // a fixed instant, so every run prints the same
console.log(`Node ${process.version}, ICU ${process.versions.icu}, CLDR ${process.versions.cldr}\n`);

const LOCALES = [
  ['en-IN', 'English (India)'],
  ['en-US', 'English (US)'],
  ['en-GB', 'English (UK)'],
  ['de-DE', 'German (Germany)'],
  ['ja-JP', 'Japanese (Japan)'],
];
console.log('Short date, as each locale writes it:');
for (const [tag, name] of LOCALES) {
  const short = new Intl.DateTimeFormat(tag, { dateStyle: 'short', timeZone: 'UTC' }).format(instant);
  console.log(`  ${tag.padEnd(6)} ${name.padEnd(18)} ${short}`);
}

const monthWord = new Intl.DateTimeFormat('en-US', { dateStyle: 'long', timeZone: 'UTC' }).format(instant);
console.log(`\nMonth as a word (en-US, long): ${monthWord}`);
console.log(`ISO 8601 (toISOString):        ${instant.toISOString().slice(0, 10)}`);

Node v24.21.0, ICU 78.3, CLDR 48.0

Short date, as each locale writes it:
  en-IN  English (India)    04/03/26
  en-US  English (US)       3/4/26
  en-GB  English (UK)       04/03/2026
  de-DE  German (Germany)   04.03.26
  ja-JP  Japanese (Japan)   2026/03/04

Month as a word (en-US, long): March 4, 2026
ISO 8601 (toISOString):        2026-03-04

Five locales give five short forms, and two of them, 04/03/26 and 3/4/26, put the day and the month in opposite places. Only the last two lines read the same everywhere: the month as a word, and the ISO date, which runs from the largest unit to the smallest. Keep a Changelog recommends ISO dates for that reason, and ISO dates in file names and logs sort in time order. Which of the two forms to use depends on where the date appears:

A time needs its zone, and IST is not one name

Google’s style guide uses the 12-hour clock with AM and PM, as in “3 PM”, and asks for the zone when it matters: spell out the region and give the UTC or GMT offsetUTC offset: How far a time zone is ahead of or behind Coordinated Universal Time (UTC), such as UTC+5:30 for India Standard Time, or UTC-5 for New York without daylight saving. in parentheses, as in “US and Canadian Pacific Standard Time (UTC-8)”. It adds, “Don’t abbreviate the name of the time zone.” Abbreviations are where time zones go wrong, because one abbreviation can name two zones. The program asks the CLDR data in Node.js for the short name of one moment:

// The short zone name that the Unicode CLDR data in Node.js gives one time in four English locales. "IST" names India
// Standard Time in one locale and Irish Standard Time in another, and two locales show no abbreviation for India at all.

const zoneName = (locale, timeZone, instant) =>
  new Intl.DateTimeFormat(locale, { timeZone, timeZoneName: 'short', hour: '2-digit', minute: '2-digit', hourCycle: 'h23' })
    .formatToParts(instant)
    .find((p) => p.type === 'timeZoneName').value;
const clock = (timeZone, instant) =>
  new Intl.DateTimeFormat('en-GB', { timeZone, hour: '2-digit', minute: '2-digit', hourCycle: 'h23' }).format(instant);

console.log(`Node ${process.version}, CLDR ${process.versions.cldr}, tz ${process.versions.tz}\n`);
const july = new Date(Date.UTC(2026, 6, 15, 9, 0)); // a fixed instant in July, when Dublin is on daylight saving time
const ROWS = [
  ['en-IN', 'Asia/Kolkata'],
  ['en-US', 'Asia/Kolkata'],
  ['en-GB', 'Asia/Kolkata'],
  ['en-IE', 'Europe/Dublin'],
];
console.log('locale  zone            local time  short name');
for (const [locale, tz] of ROWS) {
  console.log(`${locale.padEnd(7)} ${tz.padEnd(15)} ${clock(tz, july).padEnd(11)} ${zoneName(locale, tz, july)}`);
}
console.log('\nThe same 09:00 UTC as a message would put it, with the zone spelled out:');
console.log(`  ${clock('Asia/Kolkata', july)} India Standard Time (UTC+5:30), ${clock('Europe/Dublin', july)} in Dublin (UTC+1)`);

Node v24.21.0, CLDR 48.0, tz 2026c

locale  zone            local time  short name
en-IN   Asia/Kolkata    14:30       IST
en-US   Asia/Kolkata    14:30       GMT+5:30
en-GB   Asia/Kolkata    14:30       GMT+5:30
en-IE   Europe/Dublin   10:00       IST

The same 09:00 UTC as a message would put it, with the zone spelled out:
  14:30 India Standard Time (UTC+5:30), 10:00 in Dublin (UTC+1)

The Indian English data names India’s zone “IST”, the Irish English data names Dublin’s daylight saving time “IST” as well, and the US and UK English data show India as “GMT+5:30”. In documentation, spell the zone out as Google asks: “India Standard Time (UTC+5:30)”. In chat, the abbreviation with its offset, “IST (UTC+5:30)”, is enough, because the offset leaves one reading; naming a city works too. The same goes for EOD: write “by 6 PM India Standard Time (UTC+5:30) on Wednesday”. Step through one invite posted from Pune to a channel shared with London and New York:

Three more skills have parts of their own below. Daylight savingdaylight saving time: Moving the clocks forward one hour for part of the year, as the US and the UK do, on different Sundays. India does not use it, so its offset from UTC never changes. moves the clocks of the US and the UK on different Sundays and India’s never, so a meeting fixed in India Standard Time moves for colleagues abroad. Large numbers change their grouping and their names between the Indian and the international system. Versions, IDs and percentages have spoken forms that keep every digit clear.

Daylight saving: one 10:00 IST stand-up through the US and UK clock changes Pro: opens with a Pro, Premium or Ultimate pass

Lakh and crore for readers abroad, converted and said aloud Pro: opens with a Pro, Premium or Ultimate pass

Versions, IDs, percentages and units, said aloud Pro: opens with a Pro, Premium or Ultimate pass

Practise: three messages with dates and times nobody can misread

The exercise holds three short messages with dates and times that a reader in another office could misread. Fix them until the sample tests pass:

// Rewrite each message so that readers in Pune, London and New York take the same date and time from it.
export const messages = [
  'Release call at 10 tomorrow, please join.',
  'Send the test report by EOD.',
  'Maintenance window: 04/11/26, 02:00-04:00.',
];

import { test, assert } from 'mysmartcopilot:test';
import { messages } from './messages.mjs';

// The lesson's rules for dates and times that travel.
const NUMERIC_DATE = /\b\d{1,2}[/.-]\d{1,2}[/.-]\d{2,4}\b/;
const TIME = /\b\d{1,2}(?::\d{2})?\s?(?:AM|PM)?\b/;
const ZONE = /\b(?:UTC|GMT)\b|\(UTC[+-]\d{1,2}(?::\d{2})?\)/;
const DAY = /\b(?:Monday|Tuesday|Wednesday|Thursday|Friday|Saturday|Sunday)\b|\b(?:January|February|March|April|May|June|July|August|September|October|November|December)\b|\b\d{4}-\d{2}-\d{2}\b/;

test('there are still three messages', () => {
  assert.equal(messages.length, 3, 'keep three messages');
});

test('no date in numbers only', () => {
  messages.forEach((m, i) => assert.ok(!NUMERIC_DATE.test(m), `message ${i + 1}: "${m.match(NUMERIC_DATE)?.[0]}" can be read two ways`));
});

test('every time has its zone', () => {
  messages.forEach((m, i) => {
    assert.ok(TIME.test(m), `message ${i + 1} has no time`);
    assert.ok(ZONE.test(m), `message ${i + 1}: give the time a zone, UTC or a zone with its offset`);
  });
});

test('no EOD or EOW, and no tomorrow', () => {
  messages.forEach((m, i) => {
    assert.ok(!/\bEO[DW]\b/.test(m), `message ${i + 1}: replace EOD or EOW with a time and its zone`);
    assert.ok(!/\btomorrow\b/i.test(m), `message ${i + 1}: name the day instead of tomorrow`);
    assert.ok(DAY.test(m), `message ${i + 1}: name the day, with a weekday or a date`);
  });
});

test('every fact stays', () => {
  const facts = [['release call', 0], ['test report', 1], ['maintenance', 2]];
  for (const [fact, i] of facts) assert.ok(messages[i].toLowerCase().includes(fact.toLowerCase()), `message ${i + 1} no longer mentions "${fact}"`);
});

Then answer the questions on dates and time zones. The first question comes from the idea where your answers have been least sure:

Interview questions

Warm-up (fresher to mid-level): How do you write a meeting time for colleagues in India, the UK and the US?

Give one time in the organiser’s zone, spelled out with its UTC offset, and the same moment for the other offices: “10:00 India Standard Time (UTC+5:30) on Tuesday, which is 04:30 in London and 23:30 on Monday in New York” while neither country is on daylight saving time. Avoid bare abbreviations, since “IST” also names Irish Standard Time, and avoid “EOD”, which means a different hour in each office. Write the date with the month as a word, and check the conversion again whenever US or UK clocks change, because India’s never do.

Three longer questions on numbers, dates and times wait in this module’s bank:

Key takeaways

• Write dates with the month as a word, or in ISO 8601 order, never in numbers alone.
• Give a time with its zone spelled out or with its UTC offset, because abbreviations such as IST name more than one zone.
• Replace EOD with a time and a zone, and give readers in other offices their own time when it helps.