Ex: Re: shibboleth.expiring-password.Condition in v4
Paul B. Henson
henson at cpp.edu
Fri Aug 28 19:23:32 UTC 2020
> From: Cantor, Scott
> Sent: Friday, August 28, 2020 6:55 AM
> The best advice I have is to read the javadocs, this is obviously not anything we
> wrote, it's just plain Java formatting.
Been there, done that, left with bumps on my head and holes in the wall :). If I was writing Java directly, I think I could have figured it out, but all of the links about the error I was receiving talked about bugs in people's Java code that needed to be fixed, and all I had to muddle with was the format string of the existing predicate.
> I believe Date is the wrong class entirely, BTW, that's the dead Java API, the
> new stuff is very different. So I thihnk you went sideways way early on this. The
> new package is java.time
var instant = Java.type("java.time.Instant");
var exp_time = instant.ofEpochSecond(1598582155);
This results in a value like "2020-08-28T02:35:55Z", which presumably could be parsed with a formatter of "yyyy-MM-dd'T'HH:mm:ssX"?
> Lastly, my formatter is: yyyyMMddHHmmssX
> Note the X. That’s how the new API models the Z in a UTC time stamp being
> present, or an actual offset.
Okay, thanks; it would be nice if the formatter just supported converting directly from a unix time_t, it's not like they aren't very common 8-/, that would avoid the extra attribute and conversion step.
I think the default formatter that comes with the distribution ("yyyyMMddHHmmss'T'") is broken though. While it will successfully parse a time, that time fails to be converted into an instant because it did not have a time zone when it was parsed?
More information about the users