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 time. (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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. UtcTime > > from 1950 to 2049. Either can be part of a Time structure which is > > represented > > 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 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 equivalent > > 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 [EMAIL PROTECTED] > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > Development Mailing List openssl-dev@openssl.org > Automated List Manager [EMAIL PROTECTED] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
