From: Mike Eisler (mre@jurassic.eng.sun.com)
Date: 03/17/97-04:17:35 PM Z
Date: Mon, 17 Mar 1997 14:17:35 -0800 (PST) From: Mike Eisler <mre@jurassic.eng.sun.com> Subject: Re: 1/1/1970 Message-ID: <Roam 0.9.4.858637055.26898.mre@jurassic.eng.sun.com> > The year 2106 sounds like an awfully long way off, though I guess Except perhaps to a physicist using the file system to record dates of future events. > the year 2000 also did when I started my career in software engineering > and now the "Y2k" problem looms ominously. However, I'd hope that The Y2K and Y2038 problems are already here. Everyone has heard the story of the credit card holder being issued a card with "00" as the expiry year and being unable to pay for dinner. I know of a corporation that uses UNIX time to record the expiration dates of 40 year term bonds and they are in a panic. As for 2106, I've heard of 100 year mortgages in some countries, and certainly 100 year leases in this country. Used that way, 2106 isn't so far off. So if the needs of scientists cannot sway us, perhaps pecuniary applications will. > by then our grandkids are as amused by V4 as we are by smoke signals. > Surely NFS v5 or even NFS v6 might then be widely deployed. Amusement != disuse. What kind of television encoding system do you use? I'm sympathetic to the concerns about 32 more bits being rendered on the wire to record 64 bit time values, but would hope that people spend a little thought more on the problem than the previous generation of programmers did about y2k. Perhaps I should have concentrated on first getting the WG to accept the problem before proposing a simple solution. -mre
This archive was generated by hypermail 2.1.2 : 03/04/05-01:45:32 AM Z CST