krb5_timestamp and 2038

[Greg Hudson]

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 
> 64-bit?

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.

> Is there a timeline?

Nothing definite, but we can't wait too long since people already bump
into this occasionally.