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