🕐 Time, Dates & Timestamps

Option B is the most complete and professional phrasing. It includes: (1) day of week for context, (2) full date in unambiguous Month DD, YYYY format, (3) time with seconds, and (4) clearly names "UTC". Key points: GMT is treated as equivalent to UTC in most practical contexts, but in professional settings "UTC" is preferred as the authoritative term (GMT is technically a time zone, UTC is a standard). Never say "AM/PM" based on a 24-hour timestamp without confirming. Option A is too vague — "on the 15th" doesn't specify month or year, and omits timezone. Option C is acceptable but uses "Greenwich Mean Time" (an informal name) and restates day-of-week redundantly. Option D guesses at a timezone with no evidence. Vocabulary: "at XX:XX UTC", "as of 09:42 UTC", "on January 15th, 2025", "UTC timestamp".

Option C is most complete and demonstrates real professional competence. It: (1) identifies the format ("Unix epoch"), (2) correctly calculates the duration (3600 s = 1 hour), (3) contextualises the absolute date (Unix timestamps count seconds since 1970-01-01T00:00:00Z; 1,737,000,000 ≈ January 16, 2025), and (4) explains why UTC is used in post-mortems — because teams may be distributed across timezones. Option A gives relative time ("10 AM server time") without specifying timezone — misleading in a global team. Option B correctly identifies the format and duration, but omits the actual date conversion and misses the timezone reasoning. Option D is wrong — Unix timestamps are perfectly parseable. In post-mortems always write: "Incident began at 2025-01-16T08:00:00Z (Unix: 1737000000) and lasted 1 hour."