betteruptime_monitor.maintenance_timezone keeps being updated when using TimeZone values instead of keys

[remkoseelig]

The Terraform documentation of betteruptime_monitor.maintenance_timezone hints on using RubyOnRails TimeZone (https://api.rubyonrails.org/classes/ActiveSupport/TimeZone.html).

However, it's not entirely clear if keys or values should be used and the behavior of the provider is different for both.

MAPPING 	= 	{ ... => ... , "Amsterdam" => "Europe/Amsterdam", ... => ... }

Using the value

Intuitively, someone would probably use the TimeZone value (e.g. Europe/Amsterdam) opposed to the key (e.g. Amsterdam). These values are accepted by the provider and provisioning would succeed. However, if you would provision the resource again (terraform apply) it would detect a change in the resource:

# betteruptime_monitor.domain_monitor_frontend will be updated in-place
  ~ resource "betteruptime_monitor" "domain_monitor_frontend" {
        id                    = "2698378"
      ~ maintenance_timezone  = "Amsterdam" -> "Europe/Amsterdam"
        # (40 unchanged attributes hidden)
    }

Analysis

It appears that the provided TimeZone value is resolved back to the key somewhere down the road, or maybe the BetterStack API returns the TimeZone key when looking up the Terraform managed monitor resource.

As a result, Terraform concludes that the configuration has changed and wants to update this resource, and this keeps going on forever.

Using the key

If you instead would use the TimeZone key (e.g. Amsterdam) as configuration, it would work and no change is detected.

Improvement suggestion

Lacking any knowledge of the internals it's hard for me to judge if the implementation of the provider can be changed, but as an end user I would expect that if the provider somehow can resolve Europe/Amsterdam to Amsterdam it should for the sake of consistently also do the same when comparing the configuration with the actual state.

Alternatively, the provider could also refuse TimeZone values, return an error and force the user to use TimeZone keys instead.

Finally, if both suggestions are difficult to implement, I'd at least update the documentation and suggest the recommended way to specify a TimeZone.