KerberosTime

[Ken Hornstein]

>> Because it's very likely most of us will still be around by the time 
>> the year 2038 rolls around. :-)
>
>ASN allows you to use up to 127 octet for representing integer, so
>using integer would not be a problem.

In theory, yes.

But if you look at the Kerberos clarification document (currently an
Internet-Draft), you'll note that almost none of the integer fields in
the Kerberos protocol messages are unconstrained integers.  In fact,
nearly all of them are constrained to 32 bits.  This is because the Kerberos
implementations themselves would break if those integers exceeded 32 bits
of precision.  So even if epoch time was used on the wire, it's very
likely that it would be constrained (maybe not, but certainly current
implementations wouldn't support it).

>SUSV# states that the mininal requirement for attributes of timeval is
>32 bit, in fact, many unix vendors uses long. In many 64 bit
>architecture, long is 64 bit: i mean, we can count up to the end of
>universe. And we can do it now, remenber:we already have 64 bit
>machines on the market. I ought to say by that time (2038) you will be
>able to see the machines very common.

I notice you never really addressed the whole leap second thing.  Does
epoch time include leap seconds?  It's never been clear to me.  But
nevertheless ....

When I looked at this, the LP64 machines I had access to at the time
(notably the Dec Alpha) used 32 bits for time_t.  This was obviously done
to maintain compatibility with existing code that assumed 32 bits for
time_t for on-disk and network data structures.  The exception to this
was the Cray hardware, but that's a special case, because they _had_ no
32 bit integer type.  So even those 64 bit machine will be in trouble the
time the year 2038 rolls around.

--Ken