| 2011-06-16 15:12:24 |
Juan J. Martínez |
description |
swift 1.4.1 (trunk) is affected.
Probably it's not completely clear, but according to following examples:
http://docs.openstack.org/cactus/openstack-object-storage/developer/content/serialized-list-output.html#d6e479
"last_modified" field should always have the format: %Y-%m-%dT%H:%M:%S.%f
The container server is using datetime.datetime.isoformat() to format the timestamp in the JSON output and that function actually doesn't show the milliseconds part if it's zero.
So you can an output like:
>>> for i in cont.list_objects_info():
... print i['name'], i['last_modified']
...
21fa54e9fc6d46639a8dc71010d94bbe.txt 2011-06-16T11:30:48.785630
220135ad5ddf4873bb2ad6697af53667.txt 2011-06-16T11:32:21.515170
22411202895a4304815ccb5d571420e4.txt 2011-06-16T11:34:40.322250
2275efcbb6154b1b86f40f3f68f09921.txt 2011-06-16T11:24:57
228a43c827c7476f99fadd65f874596c.txt 2011-06-16T12:12:55.756650
...
Which doesn't seem right in the case of 2275efcbb6154b1b86f40f3f68f09921.txt.
This is probably a bug, either in the documentation (it should specify if the .%f part is optional) or in the container server. |
swift 1.4.1 (trunk) is affected.
Probably it's not completely clear, but according to following examples:
http://docs.openstack.org/cactus/openstack-object-storage/developer/content/serialized-list-output.html#d6e479
"last_modified" field should always have the format: %Y-%m-%dT%H:%M:%S.%f
The container server is using datetime.datetime.isoformat() to format the timestamp in the JSON output and that function actually doesn't show the milliseconds part if it's zero.
So you can get an output like:
>>> for i in cont.list_objects_info():
... print i['name'], i['last_modified']
...
21fa54e9fc6d46639a8dc71010d94bbe.txt 2011-06-16T11:30:48.785630
220135ad5ddf4873bb2ad6697af53667.txt 2011-06-16T11:32:21.515170
22411202895a4304815ccb5d571420e4.txt 2011-06-16T11:34:40.322250
2275efcbb6154b1b86f40f3f68f09921.txt 2011-06-16T11:24:57
228a43c827c7476f99fadd65f874596c.txt 2011-06-16T12:12:55.756650
...
Which doesn't seem right in the case of 2275efcbb6154b1b86f40f3f68f09921.txt (it has 0 miliseconds, so it should end .000000).
This is probably a bug, either in the documentation (it should specify if the .%f part is optional) or in the container server. |
|
