Terraform v0.12.23
When a schedule with "weekly" frequency is created, the only way to specify the start time on which the schedule would run (the time of the day, f. e. 05:00PM) is to set the attribute "start_time" (f. e. to "2020-03-14T05:00:00Z". Now if you create such a schedule, and the start time is in the past, running terraform creates a validation error:
Error: "start_time" is "2020-03-14T05:00:00Z" and should be at least "5m0s" in the future
This error occurs even if the resource is unchanged, creating a lock which can only be resolved if you delete the resource, or change the attribute accordingly.
The correct behaviour would be that validation only throws errors on creation, or if the value is changed.
Affected resources:
azurerm_automation_schedule
hcl
resource azurerm_automation_schedule base_aaa_schedule_backup_volumes {
name = "base-aaa-dev-schedule-backup-volumes"
resource_group_name = azurerm_automation_account.base_aaa.resource_group_name
automation_account_name = azurerm_automation_account.base_aaa.name
frequency = "Week"
timezone = "UTC"
week_days = ["Saturday"]
start_time = "2020-03-14T05:00:00Z"
expiry_time = "2299-12-31T00:00:00Z"
description = "Runs each Saturday on 05:00 UTC."
}
When the created resource remains unchanged, no validation error should occur.
@khaliddermoumi please try 2.1.0 azurerm version, it should be fixed.
Hi, I am still getting the same error, even with the new provider 2.5.0, like the following screenshot illustrates:

Using the same code like in the post above.
resource "azurerm_automation_schedule" "aa_schedule" {
name = "base-aaa-dev-schedule-backup-volumes"
resource_group_name = "rg-meggle-la-we-infra"
automation_account_name = "aa-account-la-mon-meggle-we-infra"
frequency = "Week"
timezone = "UTC"
week_days = ["Saturday"]
start_time = "2020-03-14T05:00:00Z"
expiry_time = "2299-12-31T00:00:00Z"
description = "Runs each Saturday on 05:00 UTC."
}
Currently I am using the following terraform version and it does not solve the problem:
Terraform v0.12.24
+ provider.azurerm v2.5.0
Can anyone help me out? Has the bug in the 2.0.0 version of the AzureRM Provider already been solved? @tombuildsstuff
Just found the error. --> I put the wrong date in several times! :-(
Of course it must be in the future:

Closing since this has been fixed via #5876
I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.
If you feel this issue should be reopened, we encourage creating a new issue linking back to this one for added context. If you feel I made an error 🤖 🙉 , please reach out to my human friends 👉 [email protected]. Thanks!