resource_monitor trying to update existing start_timestamp

[VickyWinner]

Provider Version

• provider registry.terraform.io/snowflake-labs/snowflake v0.66.0

Terraform Version
Terraform v1.5.1
on windows_amd64

The version of Terraform you were using when the bug was encountered.
Terraform v1.5.1
on windows_amd64

Describe the bug
I am passing start_timestamp in UTC per doc and the resource gets created successfully. However, when I run terraform plan again, It says there is an in-place-upgrade.

  ~ update in-place

Terraform will perform the following actions:

  # module.test_01.snowflake_resource_monitor.consumer_resource_monitor will be updated in-place
  ~ resource "snowflake_resource_monitor" "consumer_resource_monitor" {
        id                        = "XXXXX_RM"
        name                      = (sensitive value)
      ~ start_timestamp           = "2023-07-17T10:13:00-04:00" -> "2023-07-17 14:13"
        # (8 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

A clear and concise description of what the bug is.

Expected behavior
Running terraform plan should say "No infrastructure changes".

Code samples and commands
https://registry.terraform.io/providers/Snowflake-Labs/snowflake/latest/docs/resources/resource_monitor#example-usage

Additional context

Upon checking, It looks like the current timestamp is being converted to EST (my local timezone) and comparing with the HCL. But it fails when terraform apply is run because the input time is already passed.

There is another issue in resource_monitor. When I try to change the input start_timestamp to modify the resource monitor to a new date/time, It wouldn't accept new input and throws below error. I am forced to delete and re-create the whole resource. Is this by design?

│ Error: error updating resource monitor XXXXXX_RM
│ 090259 (42601): Must specify frequency and start time together.

workaround
By adding lifecycle block under the resource_monitor.
lifecycle {
ignore_changes = [
start_timestamp,
]
}

[sfc-gh-swinkler]

@VickyWinner

Thank you for bringing this to my attention. Snowflake uses session parameters for determining which timezone to use. Terraform performs the create successfully, and the result of the read is different than what was used for the create, meaning that Terraform thinks a diff is necessary. I would recommend changing your user session parameters to be consistent with that of the UTC timezone. Alternatively, your workaround is also valid.

I am not sure what the best solution to fixing this in Terraform is in the long term. Perhaps a more intelligent diff calculation that takes into consideration timezones from user vs account. Or perhaps recommending to set session parameters at the provider level, which will be used for all session timezone calculations. I will need to think about it. It affects some other resources as well, which is why we need a general solution.

[kalinon]

I also am experiencing this issue on v0.72.0. There is more of a formatting issue as well.

The formatting of the time stamp seems to differ between the provider, snowflake, and state. For example, to create a resource it is documented as:

2023-11-02 00:00
YYYY-MM-DD HH:mm

Its saved in the state file as:

2023-11-01T17:00:00-07:00
YYYY-MM-DDThh:mmTZD

However, you cannot do as you suggest and use the same format as the state file to create/update the resource:

│ Error: error creating resource monitor DEMO_WH err = 002105 (42601): SQL compilation error:
│ Invalid date/time format string '2023-11-02T17:00:00-07:00': Invalid format: "2023-11-02T17:00:00-07:00" is malformed at "T17:00:00-07:00"

[kalinon]

In addition, you cannot change either the end_timestamp or start_timestamp on the resource, as it requires you to also change the frequency as well.

snowflake_resource_monitor.demo: Modifying... [id=DEMO_WH]
╷
│ Error: error updating resource monitor DEMO_WH
│ must specify frequency and start time together

[kalinon]

Also on 0.73.0

[sfc-gh-asawicki]

Hey @VickyWinner, @kalinon. Thanks for creating the issue.

We have recently merge #2214 touching dates in the snowflake_resource_monitor resource. It was the part of v0.80.0. Could you check if the issue still persists?

[kalinon]

@sfc-gh-asawicki unfortunately we are blocked from upgrading our provider until #2169 is fixed

[sfc-gh-asawicki]

@kalinon, please check out this comment #2169 (comment). This is the current behavior, which we won't be altering shortly. It is aligned with the underlying gosnowflake driver. Please define authenticator explicitly.

[kalinon]

@kalinon, please check out this comment #2169 (comment). This is the current behavior, which we won't be altering shortly. It is aligned with the underlying gosnowflake driver. Please define authenticator explicitly.

I will give that a try

[sfc-gh-asawicki]

Hey @kalinon, I will close this issue; please open a new one if you are experiencing this problem in the more recent versions of the provider.