On Tuesday 11 December 2007 22:57:43 Jerry Feldman wrote: > On Sun, 9 Dec 2007 13:47:50 +0100 > > Anders Johansson <[EMAIL PROTECTED]> wrote: > > On Friday 07 December 2007 22:03:40 Aaron Kulkis wrote: > > > Carlos E. R. wrote: > > > > -----BEGIN PGP SIGNED MESSAGE----- > > > > Hash: SHA1 > > > > > > > > The Friday 2007-11-30 at 22:22 -0600, Bryen wrote: > > > >> On Sat, 2007-12-01 at 05:00 +0100, Carlos E. R. wrote: > > > >>> rpm -q -a --queryformat "%{INSTALLTIME}\t%{INSTALLTIME:day} \ > > > >>> %{BUILDTIME:day} %-30{NAME}\t%15{VERSION}-%-7{RELEASE} \ > > > >>> %25{PACKAGER}\n" | sort | less -S > > > >> > > > >> That's very cool. What does the first column represent? I'm > > > >> assuming it is install time based on unix time? > > > > > > > > Some internal time representation, I think seconds from certain date > > > > which I think is called unix time, yes. > > > > > > Unix Time starts with t=0 seconds at > > > 00:00, between 31 Dec 1969 and 01 Jan 1970, > > > which is also knows as "the epoch." > > > > > > System time is an unsigned 32-bit number representing > > > the number of seconds since "the epoch." > > > > > > 32-bit time will run out sometime in 2038. > > > This gives us 31 years to convert to 64-bit time. > > > > Actually it's a signed long, which means 2147483647 seconds, or just over > > 68 years. An unsigned value would be about twice that > > Actually you are wrong. The Unix 95 standard required a signed int not > a signed long.
I was using the present tense. Look around in /usr/include. I dare you to find one single instance of time_t that is not a signed long __kernel_time_t is signed long __time_t is __TIME_T_TYPE, which is __SLONGWORD_TYPE, which is signed long time_t is either of the above depending on which include file you look at, but it doesn't really matter since they are defined the same What I said was "it is a signed long". What you say is "it was a signed int". Sure, it was, and we may have to convert older systems at some point, but that's a whole other story > There was a big todo about converting to 64-bit time in > the Unix 98 standard. The problem with many vendors was binary > compatibility. I was involved in this for Tru64 Unix as if affected the > Utmp/Utmpx libraries since the utmp and wtmp files contain time stamps. > We had to be able to provide binary compatibility so applications > written for the old way would work. Luckily I was able to get enough > data into the release notes so I could get my new utmp library code > done in the next release. Making the change is not hard, but making it > binary compatible is much more complex. Of course. Any change in the ABI-exposed functions is difficult. Usually vendors take the easy way out and introduce new functions (foo() versus foo64 (), for example) Anders -- Madness takes its toll -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]