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]
