5 exercises on timestamp formats, UTC conventions, and timezone vocabulary in professional IT English.
Timestamp conventions in IT
Always use UTC for logs, incidents, and cross-timezone communication
ISO 8601: the standard format — 2026-05-25T14:32:00Z (Z = UTC)
Unix epoch: seconds since 1970-01-01T00:00:00Z — used in APIs and logs
Say "UTC+N" not "GMT+N" in technical contexts — UTC is the standard
0 / 5 completed
1 / 5
An incident report says: "The alert fired at 2026-05-25T14:32:17Z." What does the Z at the end mean, and how would you read this timestamp aloud?
ISO 8601 timestamp — the Z suffix
In ISO 8601 format, Z stands for "Zulu time" — which is UTC (Coordinated Universal Time). It indicates the timestamp is in UTC, with no timezone offset.
Reading timestamps aloud:
Formal: "14 hours, 32 minutes, 17 seconds UTC on 25 May 2026"
Common: "14:32 UTC on May 25th" (seconds often omitted in speech)
Incident context: "The alert fired at 14:32 UTC"
ISO 8601 vs. alternative formats:
2026-05-25T14:32:17Z — ISO 8601 UTC (preferred in technical contexts)
2026-05-25T14:32:17+02:00 — ISO 8601 with explicit UTC offset
Mon, 25 May 2026 14:32:17 GMT — HTTP date format (RFC 7231)
Why UTC matters: Using local times in incident reports causes confusion across timezones. Always use UTC for logs, alerts, and incident timelines.
Vocabulary:
"The incident started at [time] UTC."
"All timestamps in this document are UTC."
"Please convert to UTC when logging events."
2 / 5
A cron job is scheduled to run at "03:00 UTC" daily. A teammate in Tokyo (JST = UTC+9) asks: "When does that run for me?" What do you say?
UTC to local time conversion
UTC+9 means Tokyo's time is UTC + 9 hours: 03:00 UTC + 9 hours = 12:00 JST (noon)
Why UTC+9, not UTC-9:
UTC+9 means Tokyo is 9 hours ahead of UTC
When it's 03:00 in London (UTC), it's already noon in Tokyo
Quick mental model:
UTC+N: add N hours to UTC → local time
UTC-N: subtract N hours from UTC → local time
Japan and daylight saving (D is wrong): Japan does not observe daylight saving time — JST is always UTC+9. The caveat about DST applies to EU/US timezones, not Japan.
Cross-timezone scheduling vocabulary:
"The job runs at 03:00 UTC — that's [local time] for the [city/timezone] team."
"For scheduling, I'll always anchor to UTC."
"Please convert 03:00 UTC to your local timezone before confirming."
3 / 5
A developer says: "The Unix timestamp at the time of the incident was 1716645137." What is a Unix timestamp, and approximately when did this incident occur?
Unix timestamp — definition and approximate reading
A Unix timestamp is the number of seconds elapsed since 1970-01-01T00:00:00 UTC — the Unix epoch.
Key reference points for approximation:
Unix timestamp
Approximate date
0
1970-01-01
1,000,000,000
~September 2001
1,500,000,000
~July 2017
1,700,000,000
~November 2023
1,716,645,137
~May 2024
Important distinctions:
Unix timestamp = seconds (standard)
Some languages/APIs use milliseconds — JavaScript's Date.now() returns ms
Always clarify: "Is this seconds or milliseconds?" if unsure
Vocabulary:
"The Unix epoch timestamp is [X] — that converts to [ISO date] UTC."
"This API returns Unix time in milliseconds — divide by 1,000 to get seconds."
4 / 5
An incident post-mortem timeline shows events using different timezone formats: one person wrote "14:30 GMT+2", another wrote "12:30 UTC", and a third wrote "2:30 PM EST." All three times are the same moment. What professional standard should you enforce?
Post-mortem timestamp standardisation
Mixed timezone formats in incident timelines cause:
Confusion about event order — did this happen before or after that?
Calculation errors when computing duration or time between events
Ambiguity during DST transitions — "2:30 AM EST" is ambiguous on the day clocks change
Why UTC is the standard:
UTC never changes — no daylight saving transitions
All other timezones are defined as offsets from UTC
Engineers in different timezones can all understand UTC without conversion ambiguity
Why "GMT+2" is imprecise: GMT+2 describes an offset but doesn't specify which timezone. Europe/Paris uses UTC+2 in summer and UTC+1 in winter. The offset alone is ambiguous across DST transitions.
Post-mortem timeline vocabulary:
"All times in this document are UTC."
"Please standardise timestamps to UTC before submitting to the incident log."
"For local reference: UTC+2 at time of incident = 14:30 CEST."
5 / 5
A deployment is scheduled for "the maintenance window: 02:00–04:00 local time in the EU." Why is this problematic, and how would you rewrite it?
Timezone ambiguity in scheduling
The EU spans multiple timezones:
UTC+0: Ireland, Portugal
UTC+1: UK (winter), Central Europe (winter) — CET
UTC+2: Central Europe (summer) — CEST
UTC+3: Eastern Europe (summer) — EEST
"EU local time" could mean a 3-hour difference between the westernmost and easternmost EU timezones. This is a serious ambiguity for a maintenance window.
The fix: Always specify the exact timezone with its UTC offset:
"02:00 UTC" — unambiguous, preferred
"02:00 CET (UTC+1)" — specifies the named timezone and its current offset
"02:00–04:00 UTC (that's 03:00–05:00 CET)" — adds local context for EU team
DST caveat: Even "CET" can be ambiguous — Central Europe uses CET (UTC+1) in winter and CEST (UTC+2) in summer. Always include the UTC offset explicitly to avoid DST-related confusion.
Scheduling vocabulary:
"The window is 02:00–04:00 UTC — please check your local time."
"All maintenance windows are expressed in UTC."
"The change freeze runs from [date] 00:00 UTC to [date] 00:00 UTC."