`az grafana service-account token create --time-to-live` bugs: `10y` yields corrupted expiry (year 1741); omitting the flag gives 1 day

[KeyringHardhat]

Describe the bug

az grafana service-account token create --time-to-live 10y reports success but creates an already-expired token, with the expiry set to the year 1741. Separately, omitting --time-to-live produces a 1-day token rather than the no-expiry default reported in #8155, and the server-side maximum lifetime that rejects 3650d is undocumented.

Related command

az grafana service-account token create

Also referenced when confirming the behavior:

az grafana service-account token list
az grafana service-account create

Errors

Two --time-to-live problems observed against an Azure Managed Grafana workspace (UK South) with the amg CLI extension:

1. --time-to-live 10y creates a token with a corrupted expiration. The create call succeeds and returns a key, but az grafana service-account token list shows "expiration": "1741-11-02T16:32:48Z" with "hasExpired": true - the token is born expired (year 1741 suggests an arithmetic/overflow bug in duration parsing for the y unit). No error or warning is raised at creation time.

2. Omitting --time-to-live yields a 1-day token, whereas issue Customer feedback | az grafana service-account token create | default value for --time-to-live is no expiry, not 1 day as stated #8155 states the effective default is no expiry. On our instance the created token had exactly 24 hours (secondsUntilExpiration ≈ 86400). Either the behavior differs per instance/server config or the documentation and issue are out of date - the actual default should be documented unambiguously.

Additionally, --time-to-live 3650d was rejected by the server with The expiration date input exceeds the limit for service account access tokens expiration date, but the value of that limit is not documented anywhere we could find, and the 10y case above bypasses the limit check entirely (it creates the broken token instead of rejecting it).

Issue script & Debug output

az grafana service-account create -g <rg> -n <workspace> --service-account test-sa --role Viewer

# Case 1: corrupted expiry
az grafana service-account token create -g <rg> -n <workspace> --service-account test-sa --token t1 --time-to-live 10y
az grafana service-account token list -g <rg> -n <workspace> --service-account test-sa
# -> expiration in the year 1741, hasExpired: true

# Case 2: default is 1 day, not no-expiry
az grafana service-account token create -g <rg> -n <workspace> --service-account test-sa --token t2
az grafana service-account token list -g <rg> -n <workspace> --service-account test-sa
# -> expiration = created + 24h

Expected behavior

1. --time-to-live 10y should either create a token that genuinely expires 10 years out, or be rejected with the same clear error that 3650d produces. Silently creating an already-expired token with a year-1741 expiry is the worst outcome: the command reports success and prints a key that fails on first use, with the cause only visible via a separate token list call.
2. The default when --time-to-live is omitted should match the documentation. Whatever the real default is (no expiry per issue Customer feedback | az grafana service-account token create | default value for --time-to-live is no expiry, not 1 day as stated #8155, or 1 day as observed here), the CLI help text and the Managed Grafana docs should state it unambiguously, and the CLI should apply it consistently across instances.
3. The server-side maximum token lifetime should be documented and surfaced. The rejection message for 3650d does not say what the limit is, so there is no way to pick a valid long-lived value except by trial and error. Ideally the error names the maximum, and the docs state it alongside the --time-to-live unit list.

Environment Summary

azure-cli 2.87.0
amg extension 3.0.0
Python (Darwin) 3.13.14
Platform macOS (Darwin 25.6.0, arm64)
Install method Homebrew
Azure Managed Grafana region UK South

Additional context

No response

[yonzhan]

Thank you for opening this issue, we will look into it.

[nithin42]

Hi maintainers! 👋

I've investigated this issue and submitted PR #10195 to fix the duration unit calculation for the year (y) unit.

The bug was caused by a duplicate 30 multiplier in unit_to_seconds["y"] (3600 * 24 * 30 * 365), which evaluated 1 year as 30 years and caused 10y to overflow in Grafana's server timestamp calculation. I've corrected the multiplier to 3600 * 24 * 365, updated the help text typo, added unit tests, and bumped the extension version to 3.0.1.

Looking forward to your review!