Daylight savings time change strangeness

Jeffrey Crawford jeffreyc at ucsc.edu
Tue Mar 14 15:02:16 EDT 2017


Jeffrey E. Crawford
Enterprise Service Team <jeffreyc at ucsc.edu>

Both pilots and IT professionals require training and currency before
charging into clouds!
---------------------------------------

On Tue, Mar 14, 2017 at 11:29 AM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> > ​Right assuming the server time is correct on all sides but living in
> different
> > time zones even if one triggered it's change an hour before the other,
> the
> > SAML assertion would use UTC and they wouldn't care correct.​
>
> No, their offset to local time would be wrong, and most of the comparisons
> are to the current time. I guess in some scenarios you could have the OS
> maintaining time in UTC and some code might work, but no, generally an hour
> off is just going to break because the "get current time" API is giving you
> the wrong time back.
>
​I'm obviously being incredibly thick today​. We only saw the problem with
one vendor, all others worked as expected. Most notably we didn't have any
issues with any Shibboleth SP products, I assumed it's because both the IdP
sends the SAML timestamps in UTC and the SP compares them that way. UTC as
far as I know doesn't have daylight savings time, so that made sense to me
why they all worked (And most other vendors too).

Or am I still missing something?


> -- Scott
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170314/f482cedc/attachment.html>


More information about the users mailing list