OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

camp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Commented: (CAMP-33) Time zones and timestamps


    [ http://tools.oasis-open.org/issues/browse/CAMP-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=31815#action_31815 ] 

Adrian Otto commented on CAMP-33:
---------------------------------

Gil raises a valid concern. Although I'm tempted with the simplicity of his suggestion, I'm reluctant to require that the client send in a particular subset of ISO8601. Our choice to use JSON really means that implementations need to understand any ISO8601 complaint date/time value, and normalize them for comparison when needed.

I'm struggling to think of a use case where accepting a client supplied date would be a good idea. Clients rarely have the correct date/time set with reliable precision, whereas servers usually do have the right date/time set. It's very common for servers to use NTP protocols to synchronize server clocks to reliable precision. Consequently, PUT requests should NOT be supplied by the client. The server should ignore any client supplied "created" date, and instead set it automatically based on the server side clock in the first place. That completely eliminates the concern about interpreting any offset sent by the client because any client supplied "created" date would always be ignored. We should discuss opening another issue to remove the requirement for the "created" attribute from the client perspective, and only require it to be set by the server upon processing a PUT request. 

> Time zones and timestamps
> -------------------------
>
>                 Key: CAMP-33
>                 URL: http://tools.oasis-open.org/issues/browse/CAMP-33
>             Project: OASIS Cloud Application Management for Platforms (CAMP) TC
>          Issue Type: Improvement
>            Reporter: Tobias Kunze 
>            Priority: Trivial
>
> We may want to standardize on a time zone for timestamps. E.g. http://tools.oasis-open.org/issues/browse/CAMP-32 shows a JSON response with a local time (-08:00):
>     {
>        "uri" : "http://slc03lgx.us.oracle.com/campSrv/Assembly/9";,
>        "name" : "/examples",
>        "description" : null,
>        "created" : "2012-11-14T08:33-0800",
>        "tags": []
>        ...
>     }
> The questions are
>     1. Should the PaaS return
>         a. Client local time
>         b. Server local time
>         c. UTC
>         d. some other time, such as the account owner's (e.g. corporate headquarters)?
>     2. Should the time zone be client-selectable?
> Use cases:
>     A. I manage two PaaS, one in Singapur, one in Ireland. I was firefighting at 4am when my pager went off and then made some more changes around 9am. I want to see all operations on my dashboard in one local time so I don't have to do mental gymnastics correlating Singapur times with Ireland.
>     B. My PaaS provider in Virginia sent me an outage notice for 6:07am - 6:23am EDT. I am in Arizona which I don't even know the time zone of. Checking the management command history, I'd prefer them to be in server local time (EDT).
>     C. My company is headquartered in Johannesburg. My PaaS provider is in Tokyo. I am on assignment in China. I do NOT want the provider to be "smart" and bombard me with corporate HQ time. I'd like to get times in China time, or at least in UTC so I can think in simple offsets.
> It seems to me that
>     * For A,
>         - 1a is preferred but requires 2
>         - 1b should never be the default
>         - 1c is acceptable since I can manage one simple addition/subtraction
>         - 1d is unacceptable
>     * For B,
>         - 1a should not be the default
>         - 1b is preferred but (from A above) requires 2
>         - 1c is acceptable, as above
>         - 1d is unacceptable
>     * For C,
>         - 1a, 1b, 1c are the same as for A
>         - 1d is unacceptable by definition

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]