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. UtcTi=

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

> 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 convert =

> 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 equival=

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

> 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:
> __________________________________________________ ____________________
> OpenSSL Project
> Development Mailing List
> Automated List Manager

__________________________________________________ ____________________
OpenSSL Project
Development Mailing List
Automated List Manager