Mailinglist Archive: opensuse (3156 mails)

< Previous Next >
Re: [opensuse] I should have known!
  • From: Anders Johansson <ajh@xxxxxxxxxx>
  • Date: Tue, 11 Dec 2007 23:18:06 +0100
  • Message-id: <200712112318.06184.ajh@xxxxxxxxxx>
On Tuesday 11 December 2007 22:57:43 Jerry Feldman wrote:
On Sun, 9 Dec 2007 13:47:50 +0100

Anders Johansson <ajh@xxxxxxxxxx> wrote:
On Friday 07 December 2007 22:03:40 Aaron Kulkis wrote:
Carlos E. R. wrote:
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)


Madness takes its toll
To unsubscribe, e-mail: opensuse+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse+help@xxxxxxxxxxxx

< Previous Next >