Add DateTime calculation Capabilities with utcnow() in ARM Templates
Having the possibility to generate SAS Tokens using listaccountsas() is a great step forward in arm template functions as it enables us to generate tokens to make use of linked templates residing on protected storage. However, we still have to provide a static value for token expiration to make use of that function.
Being able to use datetime calculation functions together with utcnow() would enable us to close a gap and generate SAS tokens dynamically.
A possible scenario could look like:
addhours(parameters(utcnow(),1))
and provide the result as expiration time inside the listaccountsas() function
Fabian Flanhardt
shared this idea
Thanks for the valid suggestion. Your feedback is now open for the user community to upvote which allows us to effectively prioritize your request against our existing feature backlog and also gives us insight into the potential impact of implementing the suggested feature.
10 comments
-
sa_crowee
commented
Also need a way to output date in seconds since 1970-01-01T00:00:00Z so this can be generated during an ARM deployment eg for use in the nbf / exp fields in keyvaults.
-
Anonymous
commented
What I'd personally like is something that allows you to set a certain time of day and it returns the first time in the future that it will be that time as a full date. Possibly with an extra parameter to set a range that it should not be able to return from now since it might still return something that is for example closer than the 5 minutes in the future an automation schedule requires.
-
Greg Lloyd
commented
Looks like they published some updates on 4/6/2020 which allows for this now.
https://docs.microsoft.com/en-us/azure/azure-resource-manager/templates/template-functions-dateJust did a test on it myself and it did generate the SAS Token and pull a linked template from Blob Storage.
-
David Gard
commented
It's truely disappointing that this is still not available.
In our case, we want to use SAS tokens generated by the ARM template (listServiceSas() and listAccountSas), but because we're unable to generate an expirey date in the future by using utcNow() we've had to go a different way.
The closest I can get for a short lived token is -
[replace(parameters('utcNow'), '##', padLeft(string(add(int(parameters('utcNowHour')), 1)), 2, '0'))]The 'utcNow' parameter has a default value of "[utcNow('yyyy-MM-ddT##:mm:ssZ')]".
The 'utcNowHour' parameter has a default value of "[utcNow('HH')]".Please implement this feature properly. It will be useful to a huge amount of users.
-
Lee Hardy (Strategic Cloud Solutions)
commented
+1 for local timezone capability
-
Omer Zubair
commented
It would be great to allow local timezone variable too by default.
-
Anonymous
commented
This is making it impossible to create an automation schedule as well, because the start time needs to be in the future (by at least 5 minutes)
{
"type": "Microsoft.Automation/automationAccounts/schedules",
"apiVersion": "2015-10-31",
"name": "[concat(parameters('automationAccountName'), '/Nightly Run 2')]",
"dependsOn": [
"[resourceId('Microsoft.Automation/automationAccounts', parameters('automationAccountName'))]"
],
"properties": {
"startTime": "2019-06-16T02:00:00-05:00",
"expiryTime": "9999-12-31T17:59:00-06:00",
"interval": 1,
"frequency": "Day",
"timeZone": "America/Chicago"
}
}, -
haavardg
commented
A workaround is splitting the date up, and use the add() function to add to either the hour or day:
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"utcDateDD": {
"type": "string",
"defaultValue": "[utcNow('dd')]"
},
"utcDateMM": {
"type": "string",
"defaultValue": "[utcNow('MM')]"
},
"utcDateYYYY": {
"type": "string",
"defaultValue": "[utcNow('yyyy')]"
}
},
"variables": {
"start-date": "[concat(parameters('utcDateYYYY'),'-', parameters('utcDateMM'),'-', add(int(parameters('utcDateDD')), 1))]"
},
"resources": [
],
"outputs": {
"starttime": {
"type": "string",
"value": "[concat(variables('start-date'),'T01:00:00+01:00')]"
}
}
} -
Klaas Demter
commented
Hi,
this is coming from an issue with creation of Advanced Update Schedules (startTime needs to be in future)I would suggest to actually implement date as it is done in unix. Then you could simply say something like date(now + 1 hour) or date(tomorrow 13:00) etc
-
Fabian Flanhardt
commented
Looks like it was a little late when I posted the example. Here is a more accurate one: ;-)
addhours(parameters('utcnow'),1))