On 12/01/2014 06:09 AM, Tomas Kuthan wrote:
> as you all probably know, krb5_timestamp currently represented as 32-bit
> signed integer will overflow in 2038.
> Is there already a plan in place to fix it?
> What is the most likely fix, will krb5_timestamp be made unsigned, or
My current plan is to add API functions to convert from krb5_timestamp
to time_t, and use them internally wherever we do time computations. On
systems with 64-bit time_t, negative krb5_timestamp values will be used
to represent times between 2038 and 2106.