gpg expiration date format

[Werner Koch]

On Mon, 11 Nov 2002 07:41:35 -0500, David Shaw said:

> This would only be for use with GPGME.  With GPGME, the "user" is a
> program so it probably already has all its times in epoch form so leap
> seconds, etc, are already resolved.  Perhaps it would be better to

There is another problem with Epoch which is more real for most
purposes: time_t is a signed integer and on most systems it is 32 bit,
this means that it won't work anymore from 2038 on.  This is already
now a problem because I have seen expiration dates beyond that year
and for a couple of other applications you are interested in
years > 2038.

You can of course always use a 64 bit CPU, but in reality we have to
stay for quite some time with our 32 bit boxes.

The maintainers of glibc refuse to change time_t to a 64 bit type for
reasons I have given in my last mail.  Changing the size of time_t is
not a correct solution because time_t was never meant to represent
calendar dates.  If one digs deeper into this, one will soon realize
that leap seconds and the year 2038 is only the tip of a iceberg.

There are proposals for a new time API in C but there is no agreement
on it and no implementation.  A few months ago we looked into this and
started to work on a new API (libxtime) based on Paul Eggert's
proposal but we have not yet found the time to complete it.  

Using strings with ISO dates is propably the best solution for now
because they provide all what is needed.  The major drawback is that
it is not a simple scalar type and you have to to memory management.

The bottom line is that we might have to change the GPGME API to
either use that vaporware libxtime or simply strings for all returned
dates.



Shalom-Salam,

   Werner