webapp:Setting date in App Service app setting converts date to different format

[sptramer]

When using the az webapp config appsettings set command to set an App Service app setting to an ISO-8601 date string (YYYY-MM-DDTHH:mm:ssZ), the date string gets converted into a date that loses time zone information and introduces uncertainty into day and month ordering.

To reproduce:

1. Create App Service.
2. Run the following command: az webapp config appsettings set --name <app-service-name> --resource-group <resource-group> --settings=BUILD_DATE=2019-12-09T19:42:25Z

Observed behaviour:

Output from above command:

[
  {
    "name": "BUILD_DATE",
    "slotSetting": false,
    "value": "12/09/2019 19:42:25"
  }
]

When observing the app setting via the portal, the date is also in the incorrect format.

Expected behaviour:

[
  {
    "name": "BUILD_DATE",
    "slotSetting": false,
    "value": "2019-12-09T19:42:25Z"
  }
]

Environment Summary

Darwin-18.7.0-x86_64-i386-64bit
Python 3.7.5
Shell: bash

azure-cli 2.0.76 *

Extensions:
front-door 1.0.2
storage-preview 0.2.9

[HimeshRavi]

So what is the az command to install the updates, if there is any? I can't seem to find it anywhere.

[SQLHorizons]

az --upgrade would be to simple to expect?

[HimeshRavi]

@SQLHorizons that would be the most logical thing, but sadly it doesn't work :/

[jiasli]

@SQLHorizons @HimeshRavi Thanks for the suggestion, but since CLI is installed on different platforms with different methods, it will be difficult for CLI to self-update.

[DOliana]

even if it's not possible to provide detailed update instructions as discussed in the documentation-issue at least for extensions it should say to use az extension update <EXTENSIONNAME>

[jiasli]

The original issue description was replaced with the contents from Azure/azure-rest-api-specs#10250 by @azure-sdk and got reopened. Is the bot going nuts?

[mav10]

I ask to re-open the issue as it is still reproducible

[reaching-for-libra]

@mav10 - for what it's worth, i see the same issue, but was able to work around it by wrapping the value in quotes, with a leading space before the date value

[vmachacek]

@jiasli I can still confirm this issue exists, its super annoying and not expected, cost me 2 hours today confirmed I'm not going crazy. Please fix it

[juanmiguel-lopez-lambdaloopers]

I am having the same problem when deploying infrastructure through Bicep. I am configuring environment variables for a Function App, one of which is an ISO-8601 date string, and is expected to be parsed by the code running in the Azure Functions as such. Once deployed, the date string gets its format changed and my code can not parse it. In my case it is not possible to use the workaroud described by @reaching-for-libra.

I am using Bicep CLI v0.26.54 .
I am using Azure CLI 2.53.0 .

[asos-martinsmith]

I just came across this too.

My app setting was not as specified after deployment and updating it in the portal to "2024-05-18T00:00:00.000Z" also just converts it to 05/18/2024 00:00:00 and this is not accepted as a valid format for a CosmosDB StartFromTime attribute.

Is Newtonsoft.Json in use in the function apps project? Because reminds me very much of this bug JamesNK/Newtonsoft.Json#862

For the CosmosDB trigger case I think that the leading space will work - as looks like it uses TryParse

DateTime.TryParse(" 2024-05-18T00:00:00.000Z", out DateTime startFromTime)

still returns a DateTime and the Kind property is not "Unspecified" - which throws the error when parsing "05/18/2024 00:00:00"

But this looks like a function app issue not CLI