Tokyo Time Is Not UTC+9: A Time Zone Is Also a Way of Working

Before I moved to Japan, a time zone was just an offset for me. Sync the server, stamp the CI build, reply to a colleague in another zone a bit later — all of it was arithmetic between +8 and +9.

After I settled in Tokyo, I realized a time zone is not a number. It is a way of working.

The Stuff That Isn't in the Number

There is something about Japanese workplaces I had never seen before: meetings almost never start exactly on the hour.

In Shanghai, "3 o'clock meeting" means the projector is on at 3:00:00 and the host is at the whiteboard, waiting. In Tokyo, "3 時から" usually means people drift in between 3:00 and 3:05, and the first thing you hear is "お待たせしました". Being five minutes late is not being late; it is the buffer that politeness leaves for you.

For an engineer, the consequence is this: there is always a 5-to-15-minute invisible buffer between your "ship time" and the customer's "perceived time". You think the deadline is T+0. In practice, it is T+grace.

The "夕方" Block on the Calendar

When I first arrived, I wrote "下班" (off work) on my calendar. Later I noticed Japanese colleagues would write "退勤", "終業", or "上がり". Later still, I noticed their calendars often had a "夕方" tag — a window between 5pm and 7pm where no hard meetings get scheduled.

That window exists for "invisible work": clearing the day's tickets, writing the daily report, replying to the emails that didn't get replied to, walking a colleague through that afternoon's commits. When an engineer goes three days without a "夕方" window, things usually break on the fourth — not the technology, the judgment.

That insight came from an incident of my own. One week I packed my calendar until 22:00 for five days straight. On the sixth day I shipped a hotfix with a race condition I couldn't reproduce locally, and it took down an unrelated service in production. The postmortem didn't finger the code as the root cause. I was too tired to write a test.

On-Call at 3 AM

Another thing I did not expect: the on-call culture is different.

In Shanghai, on-call often meant "the phone rings, you jump up" — because the customer is at work, and monitoring alerts tend to need immediate response. In Tokyo, a PagerDuty alert at 3 AM gets its priority automatically downgraded. Not because nobody cares. It is because there are almost no active users at that hour, the chance of self-recovery is high, and the system is designed to "wait 15 minutes and see if it heals itself" first.

That is the exact opposite of the "respond first, diagnose later" philosophy I came from. At first I was uncomfortable with it — "isn't this just being irresponsible?" I thought. Later I realized it is a concrete practice of separating "response" from "fix". Response is the on-call engineer's job. Fixing is workday work. At 3 AM, if you can avoid fixing, you avoid it — not out of laziness, but because a rushed fix at 3 AM causes a second incident that costs more than the original alert.

I later adopted the same pattern in my own side projects: a P2 alert between 23:00 and 07:00 sends a Slack message, not a phone call. If it self-clears within 15 minutes, we pretend nothing happened. If it doesn't, we look at it the next morning.

A Final Thought

A year ago I thought moving from Shanghai to Tokyo was relocating a server from one +8 rack to a +9 one.

Now I think it was moving from one way of looking at "time" to another. In Japan, "time" is not a resource you can carve up precisely. It is something with rhythm, with etiquette, with a part you cannot see.

For an engineer learning a new time zone, adjusting the server is enough.
For a person learning a new time zone, you have to re-do the calendar.