aws ec2 describe-snapshots: default timestamp returned is incompatible with API filters

[ghostis]

Describe the bug

When I run:

$ aws --profile profile_name ec2 --region us-east-1 describe-snapshots --filter Name=tag:infra-build,Values=2023Z | jq '.Snapshots[].StartTime'

I get:

"2023-10-03T15:31:24.241000+00:00" "2023-10-02T08:31:10.302000+00:00", etc.

When I then run:

aws --profile profile_name ec2 --region us-east-1 describe-snapshots --filter Name=start-time,Values="2023-10-03T15:31:24.241000+00:00"

I get:

{ "Snapshots": [] }

I'm pretty sure this used to work.

Regression Issue

• [X] Select this option if this issue appears to be a regression.

Expected Behavior

If I filter describe-snapshots with --filter Name=start-time using the time listed under "StartTime", I expect to get the snapshot with that specific StartTime.

Current Behavior

If I filter describe-snapshots with --filter Name=start-time using the time listed under "StartTime", I get:

{ "Snapshots": [] }

Reproduction Steps

When I run:

$ aws --profile profile_name ec2 --region us-east-1 describe-snapshots --filter Name=tag:infra-build,Values=2023Z | jq '.Snapshots[].StartTime'

I get:

"2023-10-03T15:31:24.241000+00:00" "2023-10-02T08:31:10.302000+00:00", etc.

When I then run:

aws --profile profile_name ec2 --region us-east-1 describe-snapshots --filter Name=start-time,Values="2023-10-03T15:31:24.241000+00:00"

I get:

{ "Snapshots": [] }

Possible Solution

No response

Additional Information/Context

No response

CLI version used

aws-cli/2.18.3 Python/3.12.6 Linux/6.1.0-25-amd64 exe/x86_64.debian.12

Environment details (OS name and version, etc.)

Linux 6.1.0-25-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.106-3 (2024-08-26) x86_64 GNU/Linux, Debian version 12.7, updated yesterday.

[tim-finnigan]

Thanks for reaching out. Linking documentation for reference: https://awscli.amazonaws.com/v2/documentation/api/latest/reference/ec2/describe-snapshots.html

I could reproduce the behavior that you described. However, the filter worked once I changed the timestamp to UTC with .000Z at the end. (For example, 2023-03-29T23:22:28+00:00 to 2023-03-29T23:22:28.000Z) See:

aws ec2 describe-snapshots --filters Name=start-time,Values="2018-03-29T23:22:28.000Z" 

You may have been using v1 of the AWS CLI previously, as there were changes in v2 regarding timestamp processing. If you set cli_timestamp_format to wire in your config file then it will use the v1 behavior, which will return the timestamp value exactly as received in the API response (which you could then use as directly for the start-time filter.) Hope that helps.

[ghostis]

So to confirm:

I cannot take the direct value of StartTime in the JSON output from describe-snapshot (this is all with aws cli v2 in a shell script) and feed it directly into the filter "start-time"? I have to add the time zone? That seems like a UX bug.

[tim-finnigan]

So to confirm:

I cannot take the direct value of StartTime in the JSON output from describe-snapshot (this is all with aws cli v2 in a shell script) and feed it directly into the filter "start-time"? I have to add the time zone? That seems like a UX bug.

If using v2, then you can set cli_timestamp_format = wire for a profile in your config file, for example:

[profile default]
cli_timestamp_format = wire

After doing that, the StartTime values returned from describe-snapshots will look like 2018-04-19T17:48:27.000Z instead of 2018-04-19T17:48:27+00:00. And the 2018-04-19T17:48:27.000Z format is needed for the start-time filter.

[ghostis]

Per your advice, if I run:

"aws --profile "${aws_profile}" configure set cli_timestamp_format wire"

directly after authenticating, my script works as intended.

I guess we can close this, but I still think it's a bit of a UX bug to have aws cli v2 unable to consume directly in subsequent filters the timestamps it produces without changing its default configuration.

Thanks for your help!

[tim-finnigan]

Thanks for following up here and confirming that your script is working. I think we can keep this open as it does seem if anything like a quirk that could be better documented. I'll update the title description to help with tracking going forward.