TZ is an environment variable. Each process gets its own environment that it can change at will, that is sandboxed from every other environment. This environment is copied to child processes at fork(), though an environment can be overwritten by the child of the fork() before it does the exec...() call.
The timegm looks at the current process's environment to determine what delta to apply to the timeofday, by looking at the value of TZ. You can putenv() and getenv() yourself to modify it within your own code. Read the man pages for more information on how you can exploit this feature. -Kyle H On 1/28/06, Joe Gluck <[EMAIL PROTECTED]> wrote: > 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] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
