This is a discussion on Re: does ASN1_UTCTIME_get() changes by local time zone settings - Openssl ; 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 ...
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...
Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage
OpenSSL project core developer and freelance consultant.
Funding needed! Details on homepage.
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org