[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=31888#action_31888 ]
Gilbert Pilz commented on CAMP-33:
----------------------------------
CAMP is a REST API. This means that, in both the client and the server code, there is bound to be a fair bit of comparing property values to see if/what has changed. Since CAMP defines a 'Timestamp' type as an ISO 8601 timestamp, it is reasonable to conclude that some of these comparisons will involve comparing two ISO 8601 values. AFAIK, there is no way to compare two ISO 8601 timestamps with potentially differing timezones that doesn't involve first parsing the string into its proper time value
If all CAMP timestamps were required to be expressed as UTC (with either the trailing 'Z' or the "+000" designation - doesn't matter as long as we pick one and everyone uses that) than you could:
a.) compare timestamp values with a simple string compare
b.) figure out that "2012-11-14T16:33Z" occurred before "2012-11-14T15:21Z" using a simple string compare
Now in Java, at least, it is far, far easier to create an 8601 timestamp in UTC than it is to parse an 8601 timestamp - so there is a third win in that there is less code and fewer things to go wrong.
> 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
> Components: Spec
> 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]