[openssl-users] ASN1_TIME to time_t

Jakob Bohm jb-openssl at wisemo.com
Wed Sep 6 13:27:22 UTC 2017

On 06/09/2017 14:17, Michael Wojcik wrote:
>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dmitry Belyavsky
>> Sent: Wednesday, September 06, 2017 04:12
>> Is there a way to convert ASN1_TIME to time_t or smth compatible? Quick googling does not show good results.
> We just implemented it ourselves, by parsing the data field of the (1.0.2) OpenSSL ASN1_TIME structure into a struct tm and using mktime.
> That's not ideal, since it's looking at an internal representation. Also, for some reason, 1.0.2 seems to keep the year as a two-digit value for ASN.1 UTC Time, with a window centered on 1970, while it uses a 4-digit year for ASN.1 Generalized Time. The code handles that but it makes me nervous - it's the sort of internal detail that seems likely to change.
Really?  I thought the standard window for the two-digit representation
in the DER/BER encoding was centered on 2000, at least in certificates.
But I may be mistaken.

> struct tm is local time, so you need to adjust for timezone. With Generalized Time you need to parse the offset from UTC; then you adjust your struct tm based on the difference between the ASN.1 time's offset and your local offset.
It's not as much struct tm, as it is the mktime() API.  If
available, try the BSD/GNU API timegm(), although that is
officially "obsolete".

Or you could go pure C and use the integer arithmetic that
converts broken-down Gregorian dates to a day count since an
arbitrary base, either the Gauss formula, or something based on:

  ((month < 3u ? month - 3u : month + 9u) * 367u + Yu) / 12u + mday

(Y is a single digit constant, forgot which).

(That particular formula is my reconstruction of how the calendar
was probably designed by the advisor to Julius Caesar: Worst case
year is 367 days, divide equally among 12 months, restart about 20
days before spring equinox, use a historic rounding rule represented
by Y. Of cause with Roman numerals, they would have used (month - 2)).


Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

More information about the openssl-users mailing list