1,000,000,000 sec on 2001-09-09

[vistor]

Hi, I heard that AIX internal clock with advance to 1,000,000,000 (i.e. from 9 digits to 10 digits) on 2001-09-09, anybody knows the impact and where can I find some relate issues

Thanks

 

[MikeLacey]

no.... where'd you hear that then? Mike
michael.j.lacey@ntlworld.com
Email welcome if you're in a hurry or something -- but post in tek-tips as well please, and I will post my reply here as well.

 

[vistor]

Hi Mike, thanks anyway. My collegue told me he found it during working for Y2K but I can't find any related webpages now. I've asked for more info. from IBM, now still waiting for their reply

 

[vistor]

if you are using function like gettimeinterval, gettimerid, etc... there may be trouble, check the link below

http://moka.ccr.jussieu.fr/doc_link/en_US/a_doc_lib/libs/basetrf1/getinterval.htm

please share if you have any update.

 

[aixqueen]

this is my opinion...my information .....not an official IBM statement........etc.
not my companies...or anyone else....
If you want more information you need to contact IBM AIX software support directly or your third party software vendor...or your programmers....
-----------------
AIX UNIX systems calculate the value indicating date and time
by adding 1 for each second starting at 0:00:00AM GMT/UTC
on January 1, 1970.

Currently, this value (a variable of time_type) is 9-
digit by the decimal system indication. At 1:46:40AM
GMT/UTC on September 9, 2001, this value will become 10-
digit from 9-digit. A problem will occur among the
programs setting a 9-digit fixed area for the
substitution of this value. This problem will occur due
to substituting a 10-digit value into the 9-digit fixed
area rather than substituting a 9-digit value. There will
be some possibilities for this problem to occur only at
following conditions:

1. The data are stored by the format depending on the
digits to increase or decrease the minimum required
domain for storing data.(Character lines. etc c)
2. The numbers of passing seconds are utilized by the
decimal system numbers.
3. Only the 9-digit fixed area is prepared.(Programming
mistake.)
**************************************************

As is well known, UNIX time is kept internally in seconds, counting
upward from January 1st, 1970. This number hit 1 million
(1,000,000) in March of 1973, and will hit one billion (1,000,000,000)
on Sun Sep 9 01:46:39 2001 UTC This change, from a number which can be
represented in 9 decimal digits to a 10-digit number, is not
expected to cause any problems for UNIX systems.

The reason is that, excepting for a very limited number of uses,
this value is not stored as decimal digits. Instead, it is stored as an
integer value (a 32-bit binary variable) which can be used safely
until the year 2038. The uses in UNIX of a decimal format for the
"seconds time" value are primarily in portable file formats, such as
tar, cpio, and ar. These formats have always supported at least
eleven decimal (or octal in some cases) digits, easily handling UNIX's
one-billionth "birthday".

There are no known problems in any version of AIX with this issue.
It is entirely possible that some user applications may be storing
or displaying the "seconds time" as character-based digits rather than
as a binary value. If so, and the field width used to store this
value is limited to nine places, errors will result. IBM recommends
immediate correction of such software. In practice, however, Year 2000
testing showed most applications storing time this way already
understood that the number of seconds could exceed two billion and had
coded accordingly.

We do not anticipate that this is going to be a problem, excepting
for a very limited set of erroneously coded user applications.
What this means is that 1 billion isn't adding a new position to the
value, since it is stored internally in binary. The way the time will
look to AIX is like this:

EPOCH TIME BINARY FORMAT (AIX)

999,999,999 111011100110101100100111111111
1,000,000,000 111011100110101100101000000000

As far as AIX should be concerned, it is just another second added, and doesn't
change the format.

 

[vistor]

thanks very much AIXQUEEN.

refering to the link I supplied, it is clear that the function gettimerid() will result in error :-

============================================================
EINVAL Indicates that the TimerID parameter does not correspond to an ID returned by the gettimerid subroutine, or a value structure specified a nanosecond value less than 0 or greater than or equal to one thousand million (1,000,000,000).
============================================================

fortunately, I do not use this function. Point is I'm still trying to identify what other time related functions contain potential problem?