admin 管理员组

文章数量: 1086019

Since the last update in tzdata previous week (2025b - March 22, 2025), a new timezone named America/Coyhaique was introduced.

However, BigQuery still doesn't support it and produces an error when trying to handle this timezone.

I see that BigQuery still didn't updated its internal parser to support this new timezone yet. But what should we do in these cases? Wait for them to support it? Is there an alternative approach?

EDIT 27/mar/2025: I made a mistake because I though the America/Coyhaique was removed, but it actually is a new timezone. This is why BigQuery doesn't support it.

Since the last update in tzdata previous week (2025b - March 22, 2025), a new timezone named America/Coyhaique was introduced.

However, BigQuery still doesn't support it and produces an error when trying to handle this timezone.

I see that BigQuery still didn't updated its internal parser to support this new timezone yet. But what should we do in these cases? Wait for them to support it? Is there an alternative approach?

EDIT 27/mar/2025: I made a mistake because I though the America/Coyhaique was removed, but it actually is a new timezone. This is why BigQuery doesn't support it.

Share Improve this question edited Mar 27 at 21:23 Diego Queiroz asked Mar 27 at 18:06 Diego QueirozDiego Queiroz 3,4311 gold badge27 silver badges36 bronze badges 1
  • 1 IMO the United Nations should create and maintain a time zone database for each member nation. Each nation is more expert in their own time zone rules both present and past. It is a global interest for each nation to be accurately represented. If you agree, let them know. – Howard Hinnant Commented Mar 27 at 18:30
Add a comment  | 

1 Answer 1

Reset to default 0

According to the Internet Assigned Numbers Authority (IANA) which is the time zone name from the tz database.

News for the tz database

Release 2025b - 2025-03-22 13:40:46 -0700

Briefly:

New zone for Aysén Region in Chile which moves from -04/-03 to -03.

Changes to future timestamps

Chile's Aysén Region moves from -04/-03 to -03 year-round, joining the Magallanes Region. The region will not change its clocks on 2025-04-05 at 24:00, diverging from America/Santiago and creating a new zone America/Coyhaique. (Thanks to Yonathan Dossow.)

Model this as a change to standard offset effective 2025-03-20.

Since the goal of the change was to align the Aysen region with the Magallanes region, using the "America/Magallanes" timezone may be a valid work around. Provided that the systems in question, correctly reflect the current status of that timezone.

In this case, use "-03:00" or "UTC-3." This will eliminate any reliance on potentially problematic time zone identifiers. The most reliable and universally compatible approach is to use UTC offsets directly.

本文标签: timezoneInvalid time zone in BigQueryStack Overflow