On Tuesday 11 December 2007 22:57:43 Jerry Feldman wrote:
On Sun, 9 Dec 2007 13:47:50 +0100
Anders Johansson
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: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org