azurerm_automation_schedule: skip set location if expiry_time exceed the upper limit as year 9999

[wuxu92]

also update DiffSuppressFunc start_time and expiry_time. or it will cause diff because the API will remove the second part in response value for these two field. like below

Terraform will perform the following actions:

# azurerm_automation_schedule.test will be updated in-place
  ~ resource "azurerm_automation_schedule" "test" {
    id  = "/subscriptions/85b3dbca-5974-4067-9669-67a141095a76/resourceGroups/acctestRG-230505111254079233/providers/Microsoft.Automation/automationAccounts/acctestAA-230515134829705044/schedules/acctestAS-230515134829705044"           
    name  = "acctestAS-230515134829705044"
 ~ start_time = "2024-04-15T18:01:00+02:00" -> "2024-04-15T18:01:15+02:00"
      # (9 unchanged attributes hidden)
 }                                                                                                                                                                                                                                   Plan: 0 to add, 1 to change, 0 to destroy.                                                                          

fixes: #21854

[catriona-m]

Thanks for submitting this @wuxu92. While this may resolve the error in the linked issue, a different approach here may be more useful. Perhaps we could avoid setting expiry_time as a timestamp in the Read in first place if it hasn't been specified?

[tombuildsstuff]

is there a reason we can't always send and return UTC here?

[wuxu92]

yes I think it can always send a UTC time here. but I am not sure if it will cause changes to current users if we change to UTC here.

the timezone logic introduced in this PR if @catriona-m has any context about this logic and can we change the loc to UTC safely?

[catriona-m]

if we have a user-specified value here, we would still need it to be in the timezone they have specified too I think, so we do need to check if it's the default value from the api or not

[wuxu92]

@tombuildsstuff Is this PR acceptable to resolve the issue, or do you prefer @catriona-m's suggestion to avoid setting expiry_time as a timestamp in the Read in first place if it hasn't been specified? both options seem viable to me.

[tombuildsstuff]

actually we don't need to do either approach, we can instead set the raw string value rather than parsing and then setting the date time?

[wuxu92]

that should work too. I'll update it that way.

[wuxu92]

PR updated and added a new acc test for it:

--- PASS: TestAccAutomationSchedule_oneTime_basic (158.45s)
--- PASS: TestAccAutomationSchedule_expiryTimeOfEuropeTimeZone (195.06s)
--- PASS: TestAccAutomationSchedule_requiresImport (166.47s)
--- PASS: TestAccAutomationSchedule_oneTime_complete (95.21s)
--- PASS: TestAccAutomationSchedule_oneTime_update (126.64s)
--- PASS: TestAccAutomationSchedule_hourly (91.86s)
--- PASS: TestAccAutomationSchedule_daily (94.86s)
--- PASS: TestAccAutomationSchedule_weekly (94.92s)
--- PASS: TestAccAutomationSchedule_monthly (154.84s)
--- PASS: TestAccAutomationSchedule_weekly_advanced (94.75s)
--- PASS: TestAccAutomationSchedule_monthly_advanced_by_day (92.64s)
--- PASS: TestAccAutomationSchedule_monthly_advanced_by_week_day (93.93s)

[wuxu92]

@catriona-m the API will reponse expiry_time as 9999-12-31 23:59:59 if it's not specified in request. do you mean we should not set expiry_time in the Read if it's not specify in the terraform cofiguration?

[stephybun]

Thanks @wuxu92 LGTM 🌮