KerberosTime

[Ken Hornstein]

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

Right, which is _not_ the leap second.  The problem with leap seconds is that
since you can't predict when they occur, you can't make a formula that
defines them.

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

The leap second is sort of a special case; some operating systems 
pretend that they don't exist, others handle them in the C library.
This would imply to me that we already have different interpretations
of epoch time.

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

Right, but OpenBSD under which architecture?

--Ken