Define a consistent day across timezones

WHAT THIS TESTS The interviewer wants to see that you can produce a daily figure that is identical no matter who runs the report or where, despite events arriving from many timezones with daylight saving shifts.

A GOOD ANSWER COVERS Separate storage from presentation. Store every event timestamp in UTC, which is monotonic and unambiguous, and never store a naive local time alone. At the event level, also capture the source timezone identifier such as an IANA name like America/New_York, not just a fixed offset, so daylight saving is handled correctly, plus optionally the local timestamp for auditing. Then define one canonical business reporting timezone for the report, for example the company headquarters zone, and document it. To compute the daily report, convert each UTC timestamp into the reporting timezone and truncate to the date. Because all conversion logic lives in the query and the raw data stays in UTC, the report is reproducible and can be re-cut for any timezone later.

COMMON WRONG ANSWERS Storing local times with no zone or offset, so a midnight event is unplaceable; using a fixed numeric offset instead of an IANA zone, breaking around DST transitions; or bucketing in whatever timezone the analyst's session happens to use, making the same day count differently.

LIKELY FOLLOW-UPS What about per-store local days versus one global day? How do DST transition days that have 23 or 25 hours affect the count? How do you re-aggregate if the business changes its reporting timezone?

ONE CONCRETE EXAMPLE A sale happens at 11pm on March 31 in Tokyo, stored as the UTC instant plus the zone Asia/Tokyo. If the report uses UTC, that sale lands on March 31; if it uses US Pacific, it lands on March 31 morning Pacific. Because you kept UTC plus the source zone, you can confidently assign it to either definition without re-collecting data.