Open Stack

On 6/4/13 9:13 PM, "John Dennis" <jdennis at redhat.com> wrote:

>On 06/04/2013 07:01 PM, John Wood wrote:
>> Simo, we were planning to normalize times into UTC prior to putting
>>into datastore, but didn't know if it would be too stringent to make
>>clients also conform to UTC to use the API. Using UTC on both sides of
>>the API does seem safer and more robust overall though, so we could
>>enforce this in our code base for sure.
>>
>> Would anyone out there object to a UTC-only mode of operation for
>>barbican?
>
>Time values should always be in UTC. The only time (no pun intended) a
>time value should be in local time is when it is displayed to the user
>or accepted as user input, after which it should immediately be
>converted to UTC. Following the rule that time values are always UTC
>will prevent any number of nasty problems that can easily be avoided.


The API will store all date times as UTC. However, when a customer
specifies a timezone offset in a message, we have two options. Either we
accept the message, modify the UTC time to correctly represent the
requested date time (e.g. Apply the offset) or reject the message as
malformed. 

The current iso8601 implementation allows us to do neither. In some cases
it incorrectly parses the timezone offset (or ignores it) and does not
throw an error. I'm fine with rejecting a message with an offset if that's
the way that the rest of the APIs work. Is there a way to do that with the
current olso / iso8601 implementation? I guess we could roll our own, but
that seems like something property belonging to the parsing library.


Jarret Raim