Linux (Red Hat 5.1 and 5.2) Y2K compliance

Linux (Red Hat 5.1 and 5.2) Y2K compliance

Post by Matt Harrel » Wed, 30 Dec 1998 04:00:00



I'm responsible at my job for investigating the Y2K-compliance of all
our systems.  This includes two Red Hat Linux boxes (one is 5.1 and the
other is 5.2).  I'm wondering if anyone has any ideas on Y2K-compliance
of Linux.  Neither box is using much significant 3rd party software, so
it would mostly be a matter of the OS itself.  The two boxes are used
for gateway, DNS, e-mail, firewall and web servers.  I've checked Red
Hat's web site, and found nothing on Y2K.  Anyone have any suggestions?
I'm assuming that, like most other areas, Linux will be vastly superior
to it's competition (even Windows 98 is not fully Y2K-compliant, and
neither is the UnixWare 7.0.0u that I just installed on a Compaq
Proliant 3000).  Thanks.

--
Matt Harrell            

http://my.voyager.net/mharrell

 
 
 

Linux (Red Hat 5.1 and 5.2) Y2K compliance

Post by Mark Basha » Wed, 30 Dec 1998 04:00:00


Matt,
If you check the RedHat website you'll find a Y2K statement basically
saying that the Linux (and it's derivatives) are not subject to Y2K
problems.  Unix and unix-like systems use a different date system than DOS
and Windows based systems do.

The URL for the legal statement is :

http://www.redhat.com/legal_statement.phtml

The Y2K portion is about halfway down.

Mark Bashaw


> I'm responsible at my job for investigating the Y2K-compliance of all
> our systems.  This includes two Red Hat Linux boxes (one is 5.1 and the
> other is 5.2).  I'm wondering if anyone has any ideas on Y2K-compliance
> of Linux.  Neither box is using much significant 3rd party software, so
> it would mostly be a matter of the OS itself.  The two boxes are used
> for gateway, DNS, e-mail, firewall and web servers.  I've checked Red
> Hat's web site, and found nothing on Y2K.  Anyone have any suggestions?
> I'm assuming that, like most other areas, Linux will be vastly superior
> to it's competition (even Windows 98 is not fully Y2K-compliant, and
> neither is the UnixWare 7.0.0u that I just installed on a Compaq
> Proliant 3000).  Thanks.

> --
> Matt Harrell

> http://my.voyager.net/mharrell


 
 
 

Linux (Red Hat 5.1 and 5.2) Y2K compliance

Post by Christopher Brow » Thu, 31 Dec 1998 04:00:00




Quote:>I'm responsible at my job for investigating the Y2K-compliance of all
>our systems.  This includes two Red Hat Linux boxes (one is 5.1 and the
>other is 5.2).  I'm wondering if anyone has any ideas on Y2K-compliance
>of Linux.  Neither box is using much significant 3rd party software, so
>it would mostly be a matter of the OS itself.  The two boxes are used
>for gateway, DNS, e-mail, firewall and web servers.  I've checked Red
>Hat's web site, and found nothing on Y2K.  Anyone have any suggestions?
>I'm assuming that, like most other areas, Linux will be vastly superior
>to it's competition (even Windows 98 is not fully Y2K-compliant, and
>neither is the UnixWare 7.0.0u that I just installed on a Compaq
>Proliant 3000).  Thanks.

See the URL below for more details on the issue.

--
The real problem with the the year 2000 is that there are too many zero
bits and that adversely affects the global bit density. -- Boyd Roberts


 
 
 

Linux (Red Hat 5.1 and 5.2) Y2K compliance

Post by Jeremy Mathe » Thu, 31 Dec 1998 04:00:00




Quote:>Matt,
>If you check the RedHat website you'll find a Y2K statement basically
>saying that the Linux (and it's derivatives) are not subject to Y2K
>problems.  Unix and unix-like systems use a different date system than DOS
>and Windows based systems do.

Actually, DOS (and its derivatives) do, like Unix, store dates in Y2K
formats (there may be exceptions, but this is true for the most part).

The Y2K problem is mostly about old mainframe OS's and apps, but it also
affects the external interfaces of modern OS's - such as the COMMAND.COM
'date' command.  Remember, the line between system and app is a grey
one, and I wouldn't be at all surprised to find somewhere, in some
"system" database or config script, a 2 digit date assumption in Linux
or some other Unix system.

And then, of course, there is all the user written stuff for Unix and DOS.

 
 
 

Linux (Red Hat 5.1 and 5.2) Y2K compliance

Post by Mark Basha » Thu, 31 Dec 1998 04:00:00


Jeremy,
You are correct in that most OS's store dates in the correct format
"internally".  This is where we run into problems.  Unix, being a 32bit OS from
long standing, uses a 32bit clock library that basically increments from an
arbitrary date set in the early 1970's.  Unix doesn't actually know what day
and time is, only that so much time has elapsed since January 1, 1973 (or
whatever), and the date is calculated accordingly.  This 32bit library will run
into problems, I believe, in 2027 when it hits it's limit and rolls back over
to 0.  At that point I  hope we'll be using a higher bit clock library or newer
OS rev's to alleviate the problem.

DOS and it's derivitives, utilize a different starting date and smaller bit
library so the rollover problem occurs earlier.  Only OS patches and/or
upgrades alleviate the problem fully.

On the application side, in my Y2K research for my firm, we found that only
programs which contravened correct programming practice may cause problems over
the Y2K boundary, given that your hardware and OS are Y2K compliant.  An
example of incorrect programming practice would be to query the Real-Time Clock
or BIOS clock directly to get date information and use an internal clock
library, as opposed to querying the OS clock for date information.  No
applications that we checked did this kind of thing.  Most get their clock info
from the OS.  That's not to say that a user created script or database can't
have been written incorrectly, but that in most cases, the OS, and the
applications supplied with it, will function correctly.

Mark Bashaw


> Actually, DOS (and its derivatives) do, like Unix, store dates in Y2K
> formats (there may be exceptions, but this is true for the most part).

> The Y2K problem is mostly about old mainframe OS's and apps, but it also
> affects the external interfaces of modern OS's - such as the COMMAND.COM
> 'date' command.  Remember, the line between system and app is a grey
> one, and I wouldn't be at all surprised to find somewhere, in some
> "system" database or config script, a 2 digit date assumption in Linux
> or some other Unix system.

> And then, of course, there is all the user written stuff for Unix and DOS.

 
 
 

Linux (Red Hat 5.1 and 5.2) Y2K compliance

Post by Stephen E. Halp » Fri, 01 Jan 1999 04:00:00



>Matt,
>If you check the RedHat website you'll find a Y2K statement basically
>saying that the Linux (and it's derivatives) are not subject to Y2K
>problems.  Unix and unix-like systems use a different date system than DOS
>and Windows based systems do.

While Linux may be Y2K ready, the internal "seconds since..." date
format of *NIX does not mean that any *NIX will handle dates past
December 31, 1999 correctly.  One example is NeXTstep 3.3, which
does not perform the YMD:HMS->secondsSince conversion correctly,
preventing you from correctly setting the date with either the
command line 'date' utility or the preferences GUI for dates after
December 31, 1999.  Mail in 2000 will appear to be delivered in the
year 100.  Just because its *NIX doesnt mean youre safe - consult
manufacturers, and run your own tests.

-Steve

>The URL for the legal statement is :

>http://www.redhat.com/legal_statement.phtml

>The Y2K portion is about halfway down.

>Mark Bashaw


>> I'm responsible at my job for investigating the Y2K-compliance of all
>> our systems.  This includes two Red Hat Linux boxes (one is 5.1 and the
>> other is 5.2).  I'm wondering if anyone has any ideas on Y2K-compliance
>> of Linux.  Neither box is using much significant 3rd party software, so
>> it would mostly be a matter of the OS itself.  The two boxes are used
>> for gateway, DNS, e-mail, firewall and web servers.  I've checked Red
>> Hat's web site, and found nothing on Y2K.  Anyone have any suggestions?
>> I'm assuming that, like most other areas, Linux will be vastly superior
>> to it's competition (even Windows 98 is not fully Y2K-compliant, and
>> neither is the UnixWare 7.0.0u that I just installed on a Compaq
>> Proliant 3000).  Thanks.

>> --
>> Matt Harrell

>> http://my.voyager.net/mharrell

 
 
 

Linux (Red Hat 5.1 and 5.2) Y2K compliance

Post by Christopher Brow » Fri, 01 Jan 1999 04:00:00


On Wed, 30 Dec 1998 12:58:37 GMT, Jeremy Mathers




>>Matt,
>>If you check the RedHat website you'll find a Y2K statement basically
>>saying that the Linux (and it's derivatives) are not subject to Y2K
>>problems.  Unix and unix-like systems use a different date system than DOS
>>and Windows based systems do.

>Actually, DOS (and its derivatives) do, like Unix, store dates in Y2K
>formats (there may be exceptions, but this is true for the most part).

Please define "Y2K format."

Quote:>The Y2K problem is mostly about old mainframe OS's and apps, but it also
>affects the external interfaces of modern OS's - such as the COMMAND.COM
>'date' command.  Remember, the line between system and app is a grey
>one, and I wouldn't be at all surprised to find somewhere, in some
>"system" database or config script, a 2 digit date assumption in Linux
>or some other Unix system.

It is also a hardware problem; many older embedded PC clocks store date
information with a degree of detail that really only supports their
being used in a rather brief 20-30 year period of time.

--
"Windows 98 Roast Specialty Blend coffee beans - just like ordinary
gourmet coffee except that processing is rushed to leave in the insect
larvae.  Also sold under the ``Chock Full o' Bugs'' brand name..."

 
 
 

Linux (Red Hat 5.1 and 5.2) Y2K compliance

Post by Bill Unr » Fri, 01 Jan 1999 04:00:00



Quote:>Matt,
>If you check the RedHat website you'll find a Y2K statement basically
>saying that the Linux (and it's derivatives) are not subject to Y2K
>problems.  Unix and unix-like systems use a different date system than DOS
>and Windows based systems do.

This mayt be true of the operating system (the time function returns the
number of seconds since Jan1 1970 I believe) but it is not necessarily
true of programs. Many programs use and manipulate standard dates,
rather than seconds in epoch, and they are as liable to be affected by
Y2K as anything else. Note that the time_t variable is defined
differently on various systems. On some it is a signed four byte
integer, which is 2^31approx 2 10^9 sec = 68 years =2038AD at which time
severe problems would occur (why in the world would one use signed
integer???) On the other hand by then one o
hopes that most systems might use a longer definition of time_t. Of
course some programers might have been lazy and used long int as
equivalent to time_t, or might have used some other bastardisation. So
Linux uses can look forward to fun then.
>The URL for the legal statement is :
>http://www.redhat.com/legal_statement.phtml
>The Y2K portion is about halfway down.
>Mark Bashaw


>> I'm responsible at my job for investigating the Y2K-compliance of all
>> our systems.  This includes two Red Hat Linux boxes (one is 5.1 and the
>> other is 5.2).  I'm wondering if anyone has any ideas on Y2K-compliance
>> of Linux.  Neither box is using much significant 3rd party software, so
>> it would mostly be a matter of the OS itself.  The two boxes are used
>> for gateway, DNS, e-mail, firewall and web servers.  I've checked Red
>> Hat's web site, and found nothing on Y2K.  Anyone have any suggestions?
>> I'm assuming that, like most other areas, Linux will be vastly superior
>> to it's competition (even Windows 98 is not fully Y2K-compliant, and
>> neither is the UnixWare 7.0.0u that I just installed on a Compaq
>> Proliant 3000).  Thanks.

>> --
>> Matt Harrell

>> http://my.voyager.net/mharrell

 
 
 

Linux (Red Hat 5.1 and 5.2) Y2K compliance

Post by Bill Unr » Fri, 01 Jan 1999 04:00:00



Quote:>Jeremy,
>You are correct in that most OS's store dates in the correct format
>"internally".  This is where we run into problems.  Unix, being a 32bit OS from
>long standing, uses a 32bit clock library that basically increments from an
>arbitrary date set in the early 1970's.  Unix doesn't actually know what day
>and time is, only that so much time has elapsed since January 1, 1973 (or

                                                                    ^^ 1970

Quote:>whatever), and the date is calculated accordingly.  This 32bit library will run
>into problems, I believe, in 2027 when it hits it's limit and rolls back over

                              ^^^^ 2038
Quote:>to 0.  At that point I  hope we'll be using a higher bit clock library or newer

    ^ -2 10^9 ( ie a date of 1901)

Quote:>OS rev's to alleviate the problem.

Except of course all those programmers who knew that time_t was a 4 byte
int and thus used int or long int in their programs rather than time_t.

Quote:>On the application side, in my Y2K research for my firm, we found that only
>programs which contravened correct programming practice may cause problems over
>the Y2K boundary, given that your hardware and OS are Y2K compliant.  An

Of course what "correct programming practice" is can change in time. In
1980 with 16K of memory ( or in an imbedded controller with 2 K memory)
using 2 byte years might be very "correct"
 
 
 

Linux (Red Hat 5.1 and 5.2) Y2K compliance

Post by Jeff Cros » Fri, 01 Jan 1999 04:00:00


Mark, you're right on concerning the developer's way of doing things.
Coming from a Win32 program point of view, I can say that internally Windows
NT/95/98 use internal information that goes from 1981? to year 9999, but it
depends solely on the developer as to how they interpret, display and write
that information.   The developer has free reign to display that information
in any format they choose and alot of it depends on what country they are
producing it for.   If they write to a database in a mm/dd/yy format for
example and another program chooses to use that display info for input
 without getting drilling down to the bits), things could get out of hand.


>Jeremy,
>You are correct in that most OS's store dates in the correct format
>"internally".  This is where we run into problems.  Unix, being a 32bit OS
from
>long standing, uses a 32bit clock library that basically increments from an
>arbitrary date set in the early 1970's.  Unix doesn't actually know what
day
>and time is, only that so much time has elapsed since January 1, 1973 (or
>whatever), and the date is calculated accordingly.  This 32bit library will
run
>into problems, I believe, in 2027 when it hits it's limit and rolls back
over
>to 0.  At that point I  hope we'll be using a higher bit clock library or
newer
>OS rev's to alleviate the problem.

>DOS and it's derivitives, utilize a different starting date and smaller bit
>library so the rollover problem occurs earlier.  Only OS patches and/or
>upgrades alleviate the problem fully.

>On the application side, in my Y2K research for my firm, we found that only
>programs which contravened correct programming practice may cause problems
over
>the Y2K boundary, given that your hardware and OS are Y2K compliant.  An
>example of incorrect programming practice would be to query the Real-Time
Clock
>or BIOS clock directly to get date information and use an internal clock
>library, as opposed to querying the OS clock for date information.  No
>applications that we checked did this kind of thing.  Most get their clock
info
>from the OS.  That's not to say that a user created script or database
can't
>have been written incorrectly, but that in most cases, the OS, and the
>applications supplied with it, will function correctly.

>Mark Bashaw


>> Actually, DOS (and its derivatives) do, like Unix, store dates in Y2K
>> formats (there may be exceptions, but this is true for the most part).

>> The Y2K problem is mostly about old mainframe OS's and apps, but it also
>> affects the external interfaces of modern OS's - such as the COMMAND.COM
>> 'date' command.  Remember, the line between system and app is a grey
>> one, and I wouldn't be at all surprised to find somewhere, in some
>> "system" database or config script, a 2 digit date assumption in Linux
>> or some other Unix system.

>> And then, of course, there is all the user written stuff for Unix and
DOS.