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]
