Open Stack

On Wed, 2013-06-05 at 12:36 +0000, Jarret Raim wrote:
> 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.

I would say the library needs to be fixed and an option added to refuse
any date not in UTC format.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York