I can't change the TZ because it will affect the entire system and it
is a production system running on client sites, so I can't just change
the TZ.

and the mktime wil return it in time_t but after converting it to local tim=
e.

(The only thing that I may be can do, is load the times from the cert
as local time, and compare it to the current local time as well.)

On 1/28/06, Kyle Hamilton wrote:
> From the Linux gnu libc timegm(3) manpage:
>
> For a portable version of timegm(), set the TZ environment variable to
> UTC, call mktime() and restore the value of TZ.
>
> -Kyle H
>
> On 1/28/06, Dr. Stephen Henson wrote:
> > On Sat, Jan 28, 2006, Joe Gluck wrote:
> >
> > > My mistake it was ASN1_TIME that is correct.
> > >
> > > But any way, I don't see a reason why I should not be able to convert
> > > it, if I don't care for milliseconds, time_t can represent times for
> > > up to 2038, so It should be ok to convert it to the time_t.
> > >

> >
> > An GeneralizedTime structure can represent years from 0000 to 9999. Utc=

Time
> > from 1950 to 2049. Either can be part of a Time structure which is repr=

esented
> > in OpenSSL as ASN1_TIME.
> >
> > The usual place such large data ranges are seen is in compliance tests
> > though and not commonly in practice.
> >
> > Some system time routines have undefined behaviour when asked to conver=

t out
> > of range value to time_t.
> >
> > > Any ideas, the ASN1_cmp_time does much more than what I need, because
> > > I will be comparing at least once a second (If I check the last time
> > > to be at least one second earlier.) And because they are all in my
> > > cache for hopefully lets say a year, why not convert it to time_t and
> > > just check it with > current_gmt_time ?
> > >

> >
> > Well the other reason is that you need the function timegm or its equiv=

alent
> > which is far from universally implemented.
> >
> > So if you have the equivalent to that and can sensibly do something for=

values
> > out of range then there's no reason you can't do that...
> >
> > Steve.
> > --
> > Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
> > OpenSSL project core developer and freelance consultant.
> > Funding needed! Details on homepage.
> > Homepage: http://www.drh-consultancy.demon.co.uk
> > __________________________________________________ ____________________
> > OpenSSL Project http://www.openssl.org
> > Development Mailing List openssl-dev@openssl.org
> > Automated List Manager majordomo@openssl.org
> >

> __________________________________________________ ____________________
> OpenSSL Project http://www.openssl.org
> Development Mailing List openssl-dev@openssl.org
> Automated List Manager majordomo@openssl.org
>

__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org