Four ASEAN countries have no time zone of their own

Ask any computer what time zone Cambodia is in and it will tell you Asia/Phnom_Penh. That name exists. The time zone behind it does not.

In the IANA time zone database — the one shipped with essentially every operating system, phone and programming language — Asia/Phnom_Penh, Asia/Vientiane, Asia/Kuala_Lumpur and Asia/Brunei are not zones. They are links: aliases pointing at somebody else's zone. Cambodia and Laos both resolve to Bangkok. Malaysia resolves to Singapore. Brunei resolves to Kuching, in Malaysian Borneo.

The files are not similar. They are identical.

This is checkable in about ten seconds on any machine, because a link is not a copy that drifted — it is the same file under another name. Hashing the compiled zone files gives three distinct results for seven names:

Three files, seven names. Malaysia's national time zone, as your computer holds it, is Singapore's file.

This was done deliberately, and the project says why

The database's own design document is blunt about its scope:

"the database is not designed for and does not suffice for applications requiring accurate handling of all past times everywhere, as it would take far too much effort and guesswork to record all details of pre-1970 civil timekeeping."

The working rule that follows is that two places whose clocks have agreed since 1970 do not need two zones. Where they differed only before that, one becomes a link to the other. The release notes record exactly when each ASEAN name was demoted. Cambodia and Laos went in release 2014i, in October 2014, "as they differed from existing zones only for older timestamps". Malaysia and Brunei followed in release 2022b, in August 2022.

The displaced history is not deleted. It moves to a file called backzone. The project's own build instructions describe that file:

"If you want out-of-scope and often-wrong data from the file 'backzone'…"

The shipped default does not compile it. The pre-1970 history of four ASEAN countries therefore sits in a file that the maintainers label out-of-scope and often wrong, and which is not compiled by default.

Where it stops being tidy

Not every consumer of the database takes the default. Some compile backzone; most do not. That means two pieces of software on the same machine, reading the same database version, can disagree about the past.

When we ask for the UTC offset at noon on 1 June 1945, PHP and the operating system's own zone files give different answers, even on the same machine with the same database version:

⚠️ Three of the four disagree, and they do not disagree in the same direction. Cambodia and Laos come out two hours ahead in PHP; Brunei comes out an hour behind. A single "PHP runs fast on old dates" rule of thumb would get Brunei backwards.

And the one that agrees is Malaysia — the case anyone would pick to illustrate the problem, because Malaysia is the country with the famously messy timekeeping history. It agrees precisely because its link points at Singapore, whose wartime history is in the main database rather than in the disclaimed file. The zone you would reach for is the zone that behaves.

What is actually going on in 1945

The offsets are not arbitrary. Japanese occupation moved much of the region onto Tokyo time, and the countries came off it at different moments. That history is real, and it is what backzone holds. The disagreement is not between a right answer and a wrong one. It is between a recorded answer and a declined one. The main database does not claim Cambodia was on Bangkok time in 1945; it declines to say, and falls back to the zone it now shares.

What this does not mean

It does not mean your clock is wrong. Every one of these links is correct for every timestamp since 1970, which is the database's stated scope and covers essentially all software in practice. Converting a meeting between Phnom Penh and London today gives the right answer, and will keep doing so.

It also does not mean the links are a mistake to be fixed. Merging duplicate zones is a maintenance decision with a stated rationale, and the alternative — thousands of zones differing only in pre-war detail nobody can source — is worse.

A historical timestamp with a country name attached is therefore a weaker claim than it looks, and how far you can trust it depends on which runtime is interpreting it.

What to do about it

If you convert current or future times, nothing. Use the country's name and ignore all of this.

If you store or compare timestamps from before 1970 — genealogy, archives, historical finance, anything reconstructing a date of birth or a document's signing time — do not store a zone name and a local time and assume they reconstruct an instant. Store the UTC instant, or store the offset you actually mean alongside the local time. Our timezone converter and Unix timestamp converter both work on current offsets, which is the case that is safe.

And if two of your systems disagree about a historical date by a whole number of hours, check whether one of them compiled backzone before assuming either has a bug. Neither does.

Where this comes from, and what will date it

The link lines are from the database's backward file as shipped in release 2026c. The scope statement is from the project's theory.html, the build default from its Makefile, and the two demotion dates from its NEWS file, releases 2014i and 2022b. The hashes and the offsets were measured rather than quoted: the same seven zone files hashed on one machine, and the same three instants put to PHP and to the operating system on that same machine, at database version 2026.3.

⚠️ One limit. We have shown that two runtimes disagree and identified backzone as the mechanism. We have not audited which distributions and languages compile it, so "PHP does and your OS may not" is a measurement of one configuration, not a general rule about either. Check your own before relying on the direction of the gap.

The link structure is durable — merged zones are essentially never un-merged, and the database has been shedding duplicate zones for over a decade. The most likely change is to the default build. If the project ever compiled backzone as standard, the disagreement would close, but the four countries would still have no zone of their own.