KerberosTime

[Gustavo Rios]

kenh at cmf.nrl.navy.mil (Ken Hornstein) wrote in message news:<200311071605.hA7G4BTi024842 at ginger.cmf.nrl.navy.mil>...
> >> 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 ....

I guess no! At least according to how POSIX say to make conversion
between calendar time to seconds since epoch: (year here is the *real*
year - 1900)

	sec + min * 60 + hour * 3600 + days * 86400 + (year-70)*31536000 +
	((year -69)/4) * 86400 + ((year-1)/100)*86400 + ((year+299)/400) *
86400

The last three components are to handle the leap year.

I clearly don't master timing matter, but i believe, secs since epoch
are physical count. The conversion to real world is done by software
(using your timezone rules). It is more sense, since time is absolute,
the only thing that changes is how you realize it. (I am not
physician, so correct me if i am wrong).

> 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.

Ok! I had only access to OpenBSD, it does not say so. Anyhow, these
are particular instances...

> --Ken
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

Thanks for your clarification, they are really welcome.