mktime and time_t

Even if I wrote my own library, how does it help. QNX will reset it’s date
to 1970 after the year 2038? Is there spécific QNX function to get the date
I’m unaware of ?

Rejean Senecal <rsenecal@oerlikon.ca-no-spam> wrote:

Even if I wrote my own library, how does it help. QNX will reset it’s date
to 1970 after the year 2038? Is there specific QNX function to get the date
I’m unaware of ?

QNX internally stores its date/time as 64-bit nanosecond value since
1970 – this format extends well past 2100.

Take a look at the ClockTime() function for the kernel call (rather
than Posix interface) for setting/getting the time/date.

The problem is the libraries (which you’re replacing) and any of our
utilities that are compiled/linked against those libraries – which
you would also probably have to replace. (Or, not ship at all to the
customer site.)

-David

QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.

Hello Rejean

What range of dates do you need to support?

32 bits representing a number of seconds from some agreed point in time
(which ANSI currently defines as Janurary 1, 1970) would give you a range of
136 years. Ansi says that time_t is signed. This means 1970 ± 68 years.
So your options are:

  1. Choose a different start of epoc (1970)
  2. Assume these 32 bits to be unsigned
  3. Choose not to be accurate to the second. I.E. use minutes ± 1970
    instead seconds
  4. Use a larger object (64-bit int) to store your dates and times

Keep in mind that all of these options require writing your own library
routines. Ultimately I think that the world will choose option #4. The
important thing to note is that they are ALL not compatable with time_t.
And I recomend that you don’t try to make them compatable. Otherwise your
choice will haunt you for years.

If you would like a complete library of useful functions for one of these
object types, perhaps we can help. We have, for instance, a C++ class
object called Time_n that is a 64 bit object that keeps timestamps to the
nano-second. It comes with a complete library of conversion routines, math
routines, boolean routines, etc. This object won’t solve your problems but
we can provide a comprehensive library of routines that WILL solve off of
your problems, complete with a convienent place to change the library when
they (ANSI?) do decide to change time_t.


Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net


“Rejean Senecal” <rsenecal@oerlikon.ca-no-spam> wrote in message
news:a2pbu7$q0v$1@inn.qnx.com

Even if I wrote my own library, how does it help. QNX will reset it’s
date
to 1970 after the year 2038? Is there spécific QNX function to get the
date
I’m unaware of ?

Bill Caroselli <qtps@earthlink.net> wrote:

32 bits representing a number of seconds from some agreed point in time
(which ANSI currently defines as Janurary 1, 1970) would give you a range of
136 years. Ansi says that time_t is signed. This means 1970 ± 68 years.

ANSI doesn’t say that it’s signed or that it’s the number of seconds
from anything. All that ANSI says is that it’s an arithmetic type – it
could be the number of weeks stored in a double, or a bunch of numbers
(year, month, etc.) stored in bitfields inside an unsigned integer, and
ANSI wouldn’t mind.

The requirement that time_t counts seconds since 1 Jan 1970 is POSIX;
but as far as I know, POSIX doesn’t require it to be a signed type,
either.


Wojtek Lerch QNX Software Systems Ltd.

“Wojtek Lerch” <wojtek_l@ottawa.com> wrote in message
news:a2piqb$be9$1@nntp.qnx.com

Bill Caroselli <> qtps@earthlink.net> > wrote:
32 bits representing a number of seconds from some agreed point in time
(which ANSI currently defines as Janurary 1, 1970) would give you a
range of
136 years. Ansi says that time_t is signed. This means 1970 ± 68
years.

ANSI doesn’t say that it’s signed or that it’s the number of seconds
from anything. All that ANSI says is that it’s an arithmetic type – it
could be the number of weeks stored in a double, or a bunch of numbers
(year, month, etc.) stored in bitfields inside an unsigned integer, and
ANSI wouldn’t mind.

The requirement that time_t counts seconds since 1 Jan 1970 is POSIX;
but as far as I know, POSIX doesn’t require it to be a signed type,
either.

Agreed, POSIX says that time_t can be either “Integer or real-floating type
used for time in seconds”. To make assumptions about the representation of
time, in time_t, would be an error.


Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

ANSI doesn’t say that it’s signed or that it’s the number of seconds
from anything. All that ANSI says is that it’s an arithmetic type – it
could be the number of weeks stored in a double, or a bunch of numbers
(year, month, etc.) stored in bitfields inside an unsigned integer, and
ANSI wouldn’t mind.

The requirement that time_t counts seconds since 1 Jan 1970 is POSIX;
but as far as I know, POSIX doesn’t require it to be a signed type,
either.



Agreed, POSIX says that time_t can be either “Integer or real-floating type
used for time in seconds”. To make assumptions about the representation of
time, in time_t, would be an error.

That’s why you should use double difftime(time_t t0, time_t t1) to compare
time_t values, I believe.


cburgess@qnx.com