>> 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 ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
