terraform-provider-pagerduty: `time_zone` validation breaks provider when tz database is missing

PR #473 breaks a lot of assumptions that are made about terraform providers. Currently my Mac and our CI/CD Docker containers don’t have the ZONEINFO defined. We should support gracefully falling back to no validation if this doesn’t exist and throw a warning and/or add better information about why the error occurred for end users.

// LoadLocation returns the Location with the given name.
//
// If the name is "" or "UTC", LoadLocation returns UTC.
// If the name is "Local", LoadLocation returns Local.
//
// Otherwise, the name is taken to be a location name corresponding to a file
// in the IANA Time Zone database, such as "America/New_York".
//
// The time zone database needed by LoadLocation may not be
// present on all systems, especially non-Unix systems.
// LoadLocation looks in the directory or uncompressed zip file
// named by the ZONEINFO environment variable, if any, then looks in
// known installation locations on Unix systems,
// and finally looks in $GOROOT/lib/time/zoneinfo.zip.

https://github.com/golang/go/blob/go1.16/src/time/zoneinfo.go#L615-L628

Terraform Version

$ terraform --version
Terraform v1.1.7
on darwin_arm64

Affected Resource(s)

Please list the resources as a list, for example:

  • pagerduty/resource_pagerduty_ruleset_rule.go
  • pagerduty/resource_pagerduty_schedule.go
  • pagerduty/resource_pagerduty_service.go
  • pagerduty/resource_pagerduty_service_event_rule.go
  • pagerduty/resource_pagerduty_user.go

Terraform Configuration Files

...
time_zone = "America/Los_Angles"
...

Debug Output

Error: unknown time zone America/Los_Angeles
with module.pagerduty.pagerduty_schedule.default["primary"],
on ../../../../providers/pagerduty/modules/bundle/schedule.tf line 34, in resource "pagerduty_schedule" "default":
   34:   time_zone = lookup(each.value, "time_zone", "America/Los_Angeles")

Panic Output

If Terraform produced a panic, please provide a link to a GitHub Gist containing the output of the crash.log.

Expected Behavior

Timezones that are defined work without failing.

Actual Behavior

Timezones aren’t found when the timezone database is missing.

Steps to Reproduce

  1. terraform apply when a time_zone is defined and there is no timezone database present.

References

Are there any other GitHub issues (open or closed) or Pull Requests that should be linked here? For example:

Workaround / fix

apt-get install tzdata

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Reactions: 5
  • Comments: 18 (9 by maintainers)

Most upvoted comments

Also seeing the same issue when upgrading from v2.4.1 from v2.3.0

│ Error: unknown time zone Australia/Melbourne
│ 
│   with pagerduty_schedule.primary,
│   on main.tf line 4, in resource "pagerduty_schedule" "primary":
│    4:   time_zone = "Australia/Melbourne"

Yep seeing the same issue after updating to v2.4.1.

Hello all! Great news! We just pushed release v2.4.2. I just tested it on Windows and can confirm that it fixes this issue. Please give that version a try and let us know if you’re still having troubles.

Looks like 2.4.1 does not fix this

- Using previously-installed pagerduty/pagerduty v2.4.1
Terraform has been successfully initialized!
╷
│ Error: unknown time zone Europe/Prague
│ 
│   with pagerduty_schedule.backend_basic,
│   on pagerduty_be.tf line 3, in resource "pagerduty_schedule" "backend_basic":
│    3:   time_zone = "Europe/Prague"
│ 
╵
╷

@TechIsCool @stmcallister Are we ok embedding the data into the binary? It’s a bit over 400KB. This would allow us to ensure the validation would still run on these more minimal systems and not just throw warnings.

@drastawi Looks like we’re unable to fix this one, and it seems to be causing more issues than fixing. I’m going remove this validation in the next release, unless there are any strong objections.

@stmcallister I think this issue should be reopened, I am also seeing this on 2.4.1 when running with the registry.gitlab.com/gitlab-org/terraform-images/stable:latest docker image.

Still seeing this on 2.4.1 (latest).