> Hi,
> I'm using redhat 7.4 and in bits/types.h time_t is
defined
> as long int.
> This causes a wrap in 2038 (as I'm sure you all know). I
searched the
> redhat site for date 2038 and found very little current
stuff. The
> attached post from 1998 seems to say 'all will be well'
but
> I'm having a
> hard time persuading my boss that it's clever to use a
date
> system that
> expires in 35 years. I need both date and time. I can
write
> my own date
> to/from string routines. What I don't want to do is write
> the equivalent
> of the time() function to get the current date & time. Is
> there a 64 bit
> version of time() available for the current version(s) of
linux? Does
> anyone have any other ideas?
> Thanks,
> Andy.
>
This sounds like a case of premature optimization to me.
First of all, the likelyhood is in 35 years, your code and
everything it sits on will have been replaced numerous
times.
Secondly, the 64 bit time_t value will appear in 64 bit
versions of Linux
which means you will have what you need shortly.
The time_t value includes date/time by its very nature.
To bullet proof your code, you could declare a data type,
say doubletime_t
which is a 64 bit unsigned value. I believe that is
expressed in C
as a "unsigned double long int"
(they were debating about data types and naming conventions
the
last time I was involved
in this area, I dont know what they settled on, but a good
recent
C reference should tell you.)
as I recall the spec they were working on was
short - 16 bit integer
long - 32 bit integer
double long - 64 bit integer
int - X bit integer where X is the native size of an
INTEGER on the system
32 bits on a 32 bit word size machine, 16 bits on a 16 bit
word machine
24, 64 and so on depending on CPU hardware architecture
register - same as int, but "almost" guaranteed to reside
in a hardware register
depending on availability. (actualkly the optimizers should
take care
of stuffing most frequently used INT's into hardware
registers IMHO)
stuff the time_t value into your 64 bit long and then change
the data type definition
down the road to the new 64 bit value when that becomes
available.
OR - use ctime()/localtime() to convert the 32 bit time into
separate
date and time values
in a subroutine stuff the characters into separate date time
fields
Or convert time_t into year plus julian day of year,
stuff the year into an unsigned short
(16 bits - good until the year 65,536) and the day into
an unsigned char or short
good until the year gets to be more than 365 days.)
Of course you will need custom code and will be
somewhat non-portable here or you can hope for freeware for
julian dates
search google, I believe it is around.
you will also need special subroutines to do any data/time
compares
or manipulations on your special versions of date-time.
If you are using an underlying database here, most of them
have their own DATE-TIME values (and possibly the same issue
or a more standard bulletproof format.)
--
redhat-list mailing list
unsubscribe mailto:[EMAIL PROTECTED]
https://www.redhat.com/mailman/listinfo/redhat-list
