Tracking across time zones: timestamps that survive travel

Introduction#

The short answer: store the exact moment in UTC, and keep the name of the time zone next to it. That pair lets you rebuild what the wall clock said when you made the entry, even years later.

A log line that reads "8:00 AM" feels complete on the day you write it. It stops being checkable after a flight, a move, or the weekend the clocks change. If you want a log you can trust, the timestamp is the first thing to get right, because every interval, gap and trend you read later depends on it.

Below: why plain clock times fail, what to store instead, how to write it down, and how to handle travel days when your body and the wall clock disagree.

Why a clock time alone is ambiguous#

A time zone is a rule, an offset is its current result#

A time zone is an area that observes a uniform standard time for legal, commercial and social purposes. Each zone is defined by an offset from Coordinated Universal Time (UTC). Offsets are usually a whole number of hours, though some zones add 30 or 45 minutes.

The offset is not fixed. Some areas use a different offset for part of the year: when daylight saving time (DST) is in effect, the offset increases by one hour. Chicago, for example, is 6 hours behind UTC in winter and 5 hours behind in summer. So "Chicago time" is a rule, and "UTC minus 5" is only what that rule produces on a particular date.

The repeated hour#

When clocks fall back, one local hour happens twice. An entry stamped 1:30 AM on that night could refer to either of two moments an hour apart. The same Wikipedia article notes that local time is not recommended for time-stamping where DST applies, for this reason, and that records spanning several zones are typically stored in UTC.

Nothing exotic here. A local time with no extra information points to a range of possible moments, not one.

Record the instant and the place#

A timestamp that survives travel has three parts:

• The instant, in UTC. This is the unambiguous anchor. Sorting and subtracting UTC values always gives the right intervals.
• The zone name. Use a region-style name such as America/Chicago rather than an offset. The name carries the rules, so you can work out what the local clock showed on any date. A bare offset such as -05:00 cannot tell you what the rules were on a different date.
• The local time as you saw it. Keep it as a convenience for reading, but regard it as derived from the first two.

If you log by hand in a spreadsheet, that means three columns instead of one. It feels like overhead for a week. Then it stops mattering. If you want a structure to start from, the auditable protocol template shows how to lay out a log so each field has one job.

What an unambiguous timestamp looks like#

The standard notation for this is ISO 8601. A moment is written as a date, the letter T, and a time. If the time is in UTC, you add a Z directly after it with no space. If you want to show the local offset instead, you append it as a plus or minus sign followed by hours and minutes.

Here is the same moment written three ways:

| Notation | Example | What it tells you | |---|---|---| | UTC | 2026-03-08T14:30:00Z | The exact instant, no zone rules needed | | With offset | 2026-03-08T09:30:00-05:00 | The instant plus the offset in effect | | Zone name kept separately | America/Chicago | The rules, so you can recompute local time |

Two details trip people up. A zero offset is written with a plus sign (+00:00), never as a minus zero. And ISO 8601 does not allow a space between the date and the time; the related RFC 3339 format does, which is why you will see both in the wild. If you export your log and the times look slightly different in two tools, this is often why.

One caution: the entry is only as good as the clock that produced it. If a phone is set to the wrong zone, the stored UTC value is wrong too. Letting the device set its zone automatically is safer than typing the time by hand.

When you travel, log clock time and body time separately#

Travel adds a second problem that has nothing to do with software. The CDC Yellow Book describes jet lag as a sleep disorder caused by rapid travel across time zones, with diagnostic criteria that start at crossing two zones. For the first days after a long trip, your internal clock does not match the clock on the wall.

The same chapter gives typical adjustment rates of about 1.5 hours per day after westward travel and about 1 hour per day after eastward travel. For short trips of under two days, it suggests keeping to home-base sleep hours rather than adapting to the new zone.

For a log, the point is not to manage any of that. It is that an entry like "morning check-in" can mean two different things on a travel day: the morning on the local clock, or the morning your body was still keeping. If you compare check-ins across weeks, mixing the two quietly adds noise.

A simple fix is one extra field, a plain note on which clock you followed:

• "Home time" when you kept your usual schedule on a short trip.
• "Local time" when you switched to the destination schedule.
• "Mixed" when you honestly did neither.

Self-reported data is already noisy, and one odd day after a flight is not a trend. The note does not correct the data. It just tells future-you why that stretch looks different, so you do not read a pattern into it. If you also pull in other health data, the same logic applies, and one timeline with Apple Health is easier to read when every source shares a UTC anchor.

A short habit that holds up#

You don't need a complicated system. Four habits cover most of it:

1. Let your device set its time zone automatically, and do not retype times from memory.
2. Store the UTC instant and the zone name for every entry.
3. Mark travel days with a one-word note on which clock you followed.
4. Review the first entry after landing, since that is where a wrong zone setting shows up.

OptimizedTracker records the time of each entry for you, but the same principles apply to a notebook or a spreadsheet: the record should be able to answer "when, exactly" a year from now without guesswork. A timestamp is cheap to get right on the day and expensive to reconstruct later.