How do you log a day that crossed a time zone?

A day that includes a flight across time zones is not the same length as an ordinary day, and no amount of careful record-keeping changes that, because the day itself is the odd one, not whatever you are using to hold it. Land somewhere three hours behind and lunchtime happens twice. Land three hours ahead and it does not happen at all. Whatever tool you brought along either has a way to shrug that off, or it does not.

A tracked hour does not survive the jump

Anything built on adding up duration needs a stable clock underneath the arithmetic, and a time zone change is exactly what a stable clock is not. The total on a timer is a subtraction — a stop reading minus a start reading — and that subtraction assumes both readings came from the same clock. Cross a line mid-flight and they did not. The wall clock on your phone can jump back three hours in the time it takes to land, which means a block of work that spanned the flight can come out negative, or an hour of the day can quietly go missing from the total, or get counted twice, depending on which direction you were flying and which side of the jump the tool trusts. None of these are measuring anything real. They are artifacts of a subtraction that had no business being run across a moving clock in the first place.

A log does not add anything up, so there is nothing to reconcile

A line that just says what you were doing does not have this problem, because it was never doing arithmetic to begin with. Each entry is anchored to a moment — whatever the clock in front of you actually read when you wrote it — and stays true on its own terms. It does not need to agree with the entry before it about which time zone that was, and it does not need the day to add up to twenty-four hours by the end. There is no running total anywhere for a jumped clock to corrupt. An hour that got skipped on the way there is still an hour nobody has to account for, because nobody was counting.

The strange part is the day itself, not the record

Once the arithmetic is off the table, what is left is an honestly strange day — twenty-one hours or twenty-seven, an extra sunset or a missing one, a lunch that happened once at home and once again mid-air. No amount of careful logging is going to make that day symmetrical, because it was not one. That is worth accepting rather than fighting. A calendar day is a convenient human boundary, not a law of nature, and the one time it visibly buckles is a good reminder that the record was always meant to follow your actual life, not the other way around.

What to actually write when the clock itself keeps moving

• Write in whatever local time is in front of you when you write it. Do not stop to convert an entry back to where you started; the entry is true where you are.
• Let the flight be its own line or two rather than forcing it to belong entirely to the day you left or the day you arrived. It genuinely straddled both.
• If a stretch of the day is hard to place on either date, put it wherever it sits closest to. Nobody rereading this later is going to audit which side of midnight, local or otherwise, a nap on a plane technically fell on.
• Do not try to make the hours add up to a clean twenty-four. They will not, and that is a fact about the day, not an error in the log.

TimeMap fits this without any special handling, because it was never trying to add anything up in the first place. A line, a time, a colour — written wherever you happen to be, against whatever the clock says there. A day that crossed three time zones gets exactly the same kind of entries as one that never left the house, and none of them need reconciling with each other afterward.

The next time a trip leaves you unsure what day something technically happened on, it is worth remembering that the confusion is honest. The day really was an unusual length. A record that just says what happened, without insisting the hours balance, is the one thing on that trip that does not need to be corrected once you land.