Is your feature request related to a problem? Please describe.
The timestamps in s3 ls
output are shown in the user's timezone (rather than UTC), which is fine but the TZ isn't actually printed so unless the user knows that, they might incorrectly assume it is in UTC or just aren't sure and then need to do additional checking to find out what timezone is being used.
Current output (URIs were modified for privacy):
$ aws s3 ls s3://foo/bar
2020-04-26 05:26:32 6736 bar
Describe the solution you'd like
Explicitly print the timezone or offset in the timestamps.
Example:
$ aws s3 ls s3://foo/bar
2020-04-26 05:26:32 -07:00 6736 bar
Above is with a -7 hour offset (time in Los Angeles, CA).
Describe alternatives you've considered
Could also print PDT
or America/Los_Angeles
but I think offsets are a little more clear. Could also switch to ISO 8601 or some other more standard date/time format.
Additional context
aws-cli/1.18.68 Python/3.7.5 Linux/4.4.0-31-generic botocore/1.16.18
+1
Maybe this is not exactly about this issue, but sometimes it is enough to just set TZ
environment variable before to execute awscli
, to know about timezone in output:
TZ=":US/Pacific" aws s3 ls
At least your screenshot with TZ=…
show the timezone to colleagues.
This would be dangerous as it breaks backward compatibility.
If you need timezone information, you can use this instead:
$ aws s3api list-objects --bucket foo --prefix bar/
Yes, s3api will show timezone, but I don't think users should need to switch to s3api
to find out the timezone of a timestamp. That's a poor UX.
Using the the TZ
environment variable is a good tip but you have to know that it's possible as well as know the proper format of the timezone names.
In terms of backwards compatibility, yeah, I'm sure there are those who use aws s3 ls
in scripts and parse the time. But really, s3 ls
is not meant to be scripted, it is a user-facing command meant to be a simplification of s3api
. s3api list-objects
is the more correct call to make for those using awscli
in scripts. Anyway, the major version can be bumped to denote a breaking change and those with scripts can either pin to an older version or update their scripts.
In the end, I think the issue stands. The lack of any timezone info causes ambiguity and confusion.
@vincer I agree, one should not be forced to use s3api for this. IMO the best option is that aws s3 ls
supports JSON output. (#709) JSON dates than could include timezone information.
BTW On Unix a normal ls
does not return timezone information either, it represents time in the current timezone. So from that perspective it behaves as one would expect. And using TZ
you can influence this, just as with ls
. Granted using GNU ls you can at least do: ls -l --time-style='+%Y-%m-%dT%H:%M:%S%z'
(but you have to know that it's possible as well)
Hi @vincer and @dagwieers, thank you both for your input. See issue #5045 for some more perspective on timestamps in the v1 and v2 client, especially comment https://github.com/aws/aws-cli/issues/5045#issuecomment-597907021.
@vincer are you able to move to the v2 client?
I think that this provides more use cases and information but is still a duplicate of that feature request to have a user-configurable timestamp format. If you confirm I'll link this issue to that one and mark it as such.
Thanks!
Greetings! It looks like this issue hasn’t been active in longer than a week. We encourage you to check if this is still an issue in the latest release. Because it has been longer than a week since the last update on this, and in the absence of more information, we will be closing this issue soon. If you find that this is still a problem, please feel free to provide a comment or add an upvote to prevent automatic closure, or if the issue is already closed, please feel free to open a new one.
Hi @kdaily, yes, we can move to the v2 client.
However I just tried it and it seems like the default output of s3 ls
hasn't changed.
➤ ~/aws/dist/aws --version
aws-cli/2.0.37 Python/3.7.3 Linux/4.4.0-31-generic exe/x86_64.ubuntu.14
➤ ~/aws/dist/aws s3 ls s3://foo/bar
2020-08-06 12:24:29 1244 bar
Should that timestamp be in ISO 8601 format? That's what it seemed like from that issue you linked and https://docs.aws.amazon.com/cli/latest/userguide/cliv2-migration.html#cliv2-migration-timestamp
Most helpful comment
This would be dangerous as it breaks backward compatibility.
If you need timezone information, you can use this instead: