All Timestamps UTC in 2.0

[andyjohnson]

Many feel that making timestamps universal could alleviate a lot of headaches (as was the discussion on the spec call August 6, 2014. This would be a breaking change and push the spec to 2.0. This isn't enough to move to a 2.0, but if the spec is indeed versioned that high, this issue should be revisited.

[garemoko]

+1 but when this comes round we should also consider adding a timezone or location property to the context.

[brianjmiller]

For clarity can you switch issue to be "UTC" rather than "UTF" :-).

[canweriotnow]

I can't :+1: this hard enough.

[andyjohnson]

So per the Oct 8, 2014 Working Group Meeting, we would like to make the following changes to the spec come version 2.0 all surrounding UTC. UTC is the slightly more precise version of GMT. The minutes are on the Google forums, so if I have misrepresented anything, please let me know.

1. Time Zones (i.e.an offset to the time supplied) are required (i.e. MUSTS) for both stored and timestamp properties.

2. The timestamp property SHOULD have a timezone with UTC (+00:00). What we mean by UTC in this context is that the zero offset is assumed. We will also leverage UTC offsets for time zones i.e. UTC+10:00.

3. If an AP doesn't provide a time zone/offset for timestamp, it MUST be interpreted by the LRS as UTC (+00:00).

4. All LRSs MUST populate the stored property with UTC (+00:00) time zone/offsets.

5. The group sees value in allowing an AP to specify a time zone, but as an extension. This group may pursue adding an additional property for this in a future version, but current thinking is that a profile group would add this.