Fix/managed exports japan timezone

[TakuSe (TakumiSeo)]

Changes the managed exports time zone mapping for Japan from Japan Standard Time to Tokyo Standard Time.

Azure Cost Management managed exports expect Tokyo Standard Time for the Data Factory schedule trigger. Using Japan Standard Time causes trigger validation to fail.

This supersedes #2219, which was accidentally opened from microsoft:main and did not include the intended file changes.

[Copilot]

Pull request overview

Updates the managed exports time zone mapping for Japan to use the Windows time zone ID expected by Azure Data Factory schedule triggers, preventing trigger validation failures when deploying managed exports.

Changes:

• Switch japaneast and japanwest from Japan Standard Time to Tokyo Standard Time in the Managed Exports time zone mapping.

[Roland Krummenacher (RolandKrummenacher)]

Verified beyond the diff: I extracted every timezone ID from timeZones.bicep at this PR's head and validated all 13 distinct IDs case-sensitively against the Windows timezone registry (Get-TimeZone -ListAvailable), which is what the Data Factory schedule trigger validates against. Japan Standard Time was the only invalid ID in the file — it's the IANA-style display name, not a Windows ID — and Tokyo Standard Time is the correct replacement. All other mappings (Korea, China, Singapore, India, AUS Eastern, etc.) check out, so no sibling entries have the same bug. LGTM, thanks for the fix!

[microsoft-github-policy-service]

@all-contributors please add @TakumiSeo for code

[allcontributors]

@microsoft-github-policy-service[bot]

I've put up a pull request to add TakuSe (@TakumiSeo)! 🎉

[Michael Flanakin (flanakin)]

Fix looks correct — verified Tokyo Standard Time is the right Windows time zone ID for Asia/Tokyo (there is no valid Windows ID called "Japan Standard Time"), matching the same bug class fixed for USGov regions in #2087.

One should-fix: please add a changelog entry under ## Unreleased → FinOps hubs vNext → Fixed, consistent with the precedent set by #2087.

Bonus question (not necessarily for this PR): is there a way to write a test that validates this Azure-region → Windows-timezone mapping — ideally with a completeness check (every current Azure region has an entry, every value is a real Windows time zone ID)? We keep getting one-off PRs/issues for individual regions here; I would love to catch the whole class automatically instead. Might be more of a v16 tracking issue than something to scope into this PR — curious if there is a reasonably cheap way to do it (e.g., validate against Get-TimeZone -ListAvailable or the CLDR Windows↔IANA mapping in a Pester test) before deciding where it belongs.