Date headers aren't returned with timezone

Bug #1169287 reported by John Dickinson
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
OpenStack Object Storage (swift)
Fix Released
Undecided
Kun Huang

Bug Description

Dates represented in ISO 8601 do not tell you that the time is in UTC, i.e., there should be a "Z" at end. Example: "2013-03-14T01:46:02.952040Z". As-is, it implies the dates are in local timezone.

clayg (clay-gerrard)
summary: - timezones aren't returned with timezone
+ Date headers aren't returned with timezone
Revision history for this message
Lincoln Thomas (lincoln-thomas) wrote :

Clarification: The format is indeed ISO 8601 with or without the timezone indication, but without it, there's no way to know what the actual time is, using only the API. We can't assume users can know the timezone of the server producing the output, or if it's even using that timezone. Is it also possible for different servers in the same cluster to be in different timezones?

Revision history for this message
David Hadas (david-hadas) wrote :

I am a bit confused here.
The date on my Ubuntu 12.04 is returned as:

 Date: Sun, 12 May 2013 05:33:50 GMT

Timezone GMT is indicated.
While the date is not using anything like the format described above.

Revision history for this message
Edward (zhang-hare) wrote :

here're some use cases of response headers for discussion.
------------------------------------------------------------------------
GET http://localhost:8080/v1/AUTH_e0be6510da0a4cec9bbd7c815b0a9a07/audio/?format=json
Status: 200 OK
Body:
[{"hash": "987e8359fbda349cb305e3f1b5fa4562", "last_modified": "2013-06-09T09:02:22.059070", "bytes": 2079, "name": "etc/swift/swift.conf", "content_type": "application/octet-stream"}]
Headers:
X-Timestamp: 1370768514.41576
Date: Sun, 09 Jun 2013 09:30:07 GMT

HEAD http://localhost:8080/v1/AUTH_e0be6510da0a4cec9bbd7c815b0a9a07/audio/ai.wav
Status: 200 OK
Headers:
Last-Modified: Sun, 09 Jun 2013 09:02:22 GMT
X-Timestamp: 1370768542.05907
X-Object-Meta-Mtime: 1370764207.541816
Date: Sun, 09 Jun 2013 09:32:45 GMT

-----------------------------------------------------------------------
We can see three type of time formats:
1) GMT, e.g. Sun, 09 Jun 2013 09:32:45 GMT
2) UTC without Z, e.g. 2013-06-09T09:02:22.059070
3) 16.5f, e.g. 1370764207.541816

Revision history for this message
Lincoln Thomas (lincoln-thomas) wrote :

I was referring specifically to the JSON and XML output formats for requests such as (from the OpenStack Object Storage Developer Guide API v1):

GET /<api version>/<account>/<container>?format=json HTTP/1.1

example output:

"last_modified":"2009-02-03T05:26:32.612278"

According to http://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators :

------------------
Time zone designators

Time zones in ISO 8601 are represented as local time (with the location unspecified), as UTC, or as an offset from UTC.

If no UTC relation information is given with a time representation, the time is assumed to be in local time. While it may be safe to assume local time when communicating in the same time zone, it is ambiguous when used in communicating across different time zones. It is usually preferable to indicate a time zone (zone designator) using the standard's notation.

UTC

If the time is in UTC, add a Z directly after the time without a space. Z is the zone designator for the zero UTC offset. "09:30 UTC" is therefore represented as "09:30Z" or "0930Z". "14:45:15 UTC" would be "14:45:15Z" or "144515Z".

Time offsets from UTC

The offset from UTC is given in the format ±[hh]:[mm], ±[hh][mm], or ±[hh]. So if the time being described is one hour ahead of UTC (such as the time in Berlin during the winter), the zone designator would be "+01:00", "+0100", or simply "+01". This is appended to the time in the same way that 'Z' was above. The offset from UTC changes with daylight saving time, e.g. a time offset in Chicago, would be "-06:00" for the winter (Central Standard Time) and "-05:00" for the summer (Central Daylight Time).
------------------

Therefore, the output from the HTTP response "2009-02-03T05:26:32.612278" as returned by Swift means local time (of the Swift server?). If Swift is actually returning UTC always, it should append a Z. If it is actually returning local time, then it should convert the time to UTC and append a Z, or display it with an offset e.g. "2009-02-03T05:26:32.612278-0700".

I believe it should not return local time without an offset in any case, because the user may not know what timezone the server is in, or what timezone it was in at the time it generated the output. The user may be looking at output that was generated long ago, from a server that has moved or no longer exists.

We could check this against the actual ISO 8601 spec at http://www.iso.org/iso/catalogue_detail?csnumber=40874, but it costs $142 to download it.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (master)

Fix proposed to branch: master
Review: https://review.openstack.org/38008

Changed in swift:
assignee: nobody → Kun Huang (academicgareth)
status: New → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (master)

Reviewed: https://review.openstack.org/38008
Committed: http://github.com/openstack/swift/commit/7cd01a63d340c254116da1ef9937d30048184dbe
Submitter: Jenkins
Branch: master

commit 7cd01a63d340c254116da1ef9937d30048184dbe
Author: Kun Huang <email address hidden>
Date: Sat Jul 20 09:52:56 2013 +0800

    Add 'Z' into isoformat for UTC time

    Based on this http://en.wikipedia.org/wiki/ISO_8601#Time_zone_designators.
    A isofomt of time need a 'Z' for UTC time zone, or none for local time zone

    request on GET /<version>/<account>/<container>?format=json still output a
    UTC time without 'Z'

    fixes bug #1169287
    Change-Id: Ib599b5ec8fd223878ec18df7c1ec8d952fc2630a

Changed in swift:
status: In Progress → Fix Committed
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to swift (feature/ec)

Fix proposed to branch: feature/ec
Review: https://review.openstack.org/38552

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to swift (feature/ec)
Download full text (15.3 KiB)

Reviewed: https://review.openstack.org/38552
Committed: http://github.com/openstack/swift/commit/f3ba55039c4caa91b71b453f2dc1f5310c2ac801
Submitter: Jenkins
Branch: feature/ec

commit f2c3e1af9cf0ad1fbf7753cd2e5caef9bd297cb5
Author: Samuel Merritt <email address hidden>
Date: Mon Jul 22 16:14:59 2013 -0700

    Fix bulk's unit tests on Mac OS.

    Turns out if your $TMPDIR is really long
    (e.g. /var/folders/vq/n32yszdn4s76z6l8dxklmwdh0000gn/T/, which is 50
    characters), then the test that drops stuff into $TMPDIR and adds it
    to a tarball and uploads it will fail due to every added file's name
    being too long.

    Change-Id: I8fcab2d95091f72b831b906bfc87a36d8be12631

commit 5c1a7871d9173db9fbd855b72a98ecd8ff163800
Author: Newptone <email address hidden>
Date: Sun Jul 21 12:18:24 2013 +0800

    Unified format of boolean params in conf files

    In swift conf files, boolean options use different
    format: some use true/false, and some use True/False.
    This patch is aim to using lowcase true/false to unify
    boolean params formats in swift conf files.

    Fix Bug #1203421

    Change-Id: I3e1bfc6e43231f51e0710aa54869f3774ee896b1

commit 63061e37ed098bf1ad509177484037544eb6b089
Author: Kun Huang <email address hidden>
Date: Tue Jul 23 13:46:51 2013 +0800

    Add notes for /srv/node in swift-object-info

    'devices' is set in object-server.conf on each node, not in ring data,
    and the things printed here is just for watching not for running, so
    just leave a note here. (this https://review.openstack.org/#/c/23951/
    is used for running, so just a note is not enough)

    mark this commit as bug fixing is because this script is the last place
    using /srv/node but not from conf as Chmouel said.

    fixes import change on read_metadata
    fixes bug #885006
    Change-Id: I727ec2d01c093af61fd3895e5701d87ef67cd9ff

commit 13bbe4b7c31b17efbebd91bd01586757600a082b
Author: Michael Barton <email address hidden>
Date: Mon Jul 22 21:12:22 2013 -0700

    fix unit tests in 2.6 by using closing(GzipFile)

    Python 2.6 doesn't support using GzipFile as a context manager.

    Change-Id: Ic12b5a916bc89ae8d4480879723201c1715285af

commit 6384b192b55b823d86078588f22b8bc847954aad
Author: Alex Gaynor <email address hidden>
Date: Mon Jul 22 14:59:30 2013 -0700

    Ensure that files are always closed explicitly.

    This is needed on Pythons without reference
    counting garbage collectors (e.g. PyPy).

    Change-Id: Ieb563ace9f65a4ad204b01be32bf7a9d5f226005

commit 0e3103c0dd3690f5e69ec7953c270430d0564d12
Author: Alex Gaynor <email address hidden>
Date: Mon Jul 22 15:27:54 2013 -0700

    Corrected a number of style violations in the tests.

    Change-Id: Ib5e81ad0476c56cf84d222d67f55b8db3eb0249e

commit fc293a750c8a83ec99d3b462b4689741c1e66a9b
Author: Peter Portante <email address hidden>
Date: Wed Jul 17 17:41:41 2013 -0400

    Move the mount checking into DiskFile constructor

    Move the mount checking into the DiskFile object constructor. The
    REPLICATE method does not use the DiskFile object currently, so that
    method st...

Thierry Carrez (ttx)
Changed in swift:
milestone: none → 1.9.1
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.