🚀 go-pugleaf

Gentlemen:

I am the Y2k Practice Director for Client/Server Management a Toronto Based
Conslulting Company with many clients who have done this remediation.  In our
investigations we have learned that the OS may have problems if they are not
fixed.

The current UNIX operating systems does not go past 2038. MVS may have some
problems in 204xx the number. The statements about databases is suspect
because it depends on the database management systems.	If POSIX time calls
are used it may require a significant effort.  Other DBMS can range out to
the Year 3000 and beyond.

The issue about windowing is only true if a fixed windowing technique was
used. Most companies used a sliding windowing technique which allows  the
window to slide from a 50/50 to a 40 / 60 window.

Mike Bayer

In article <7creav$fs3$1@canopus.cc.umanitoba.ca>,
  roberson@ibd.nrc.ca (Walter Roberson) wrote:
> In article <19990318.084428.24081@sol.sun.csd.unb.ca>,
> James Crooks  <jcrooks@vse.ca> wrote:
> :Is this article's statement true for most Canadian Y2K remediation
> :efforts?
>
> |From: "Mark Gibbs" <mgibbs@gibbs.com>
> |MOST Y2K FIXES WILL ONLY LAST A GENERATION
>
> |The fix used to patch 80% of the worlds' computers to avert a Y2K crisis
> |is
> |actually only a short-term remedy called "windowing."
>
> |patch is a trick that forces software to "guess" whether dates fall in
> |the
> |1900s or the 2000s;  typically, lower numbers (perhaps up to 30) will
> |belong
> |to the new century, whereas higher numbers (such as 87) will belong to
> |the
> |old century.
>
> While it is true that "windowing" has been used in a number of fixes, I
> would point out that in 2038 there will be another big date crisis:  in
> that year, UNIX and NT and all POSIX compliant systems run out of
> time.
>
> The ANSI C time_t is defined to be an "arithmetic type" [so it cannot
> be a structure], and POSIX defines time() to return time_t and requires
> that it be the number of seconds since the Epoch, with the Epoch
> defined as starting Jan 1 1970 UTC. There is no explicit requirement
> that time_t be signed but it is in practice. As a signed value the
> counter will overflow in 2038. (I've heard that Windows 95 runs out in
> 2035 for some reason.) On many 32 bit machines, a 32 bit long *is* the
> biggest "arithmetic type" available, so there isn't anywhere to expand
> to without breaking the standards. And there will always be legacy code /
> systems of course.
>
> There simply isn't any defined way at present to write POSIX compliant
> code that is certain to survive the end of the Epoch -- there is no
> time64() call etc. Filesystems will need to be converted too, as 32 bit
> timestamps are what are stored on Unix filesystems -- imagine what a mess
> that's going to be!!
>

Michael Bayer

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own