Date formats and Y2K
Steve Hayes
>G'day,
>The Y2K was not a software problem (as such). It was a hardware problem in
>that the onboard memory of early computers had enough memory assigned to the
>computer date function to handle ddmmyy. This meant that when the year
>changed from 31/12/99 to 01/01/00 then all the programs that used the
>computer time /date would "assume" that the year was 1900 instead of 2000.
>The solution was not to upgrade your software but upgrade your hardware to a
>mother board that had the necessary amount of computer memory to handle a 4
>digit year instead of the previous 2 digit year. There was very little Y2K
>drama for the simple reason that we were given lots of warning (time wise)
>and most people upgraded their hardware before 2000 which negated the
>EOTWAWKI threat.
Not so.
Computers had enough memory to deal with it from the early 1980s, but
short-sighted programmers still only allocated enough memory for two-digit
years.
One of my favourite programs, which I use a lot for genealogy, has an
automatic date entry which enters todays date as 5 February 1107, and I have
to go back and correct it. At least it can calculate the date correctly,
thoguht, unlike earlier versions of PAF, which report errors in the birth and
death dates of anyone born or died after 31 Dec 1999
--
Steve Hayes
E-mail: haye...@hotmail.com (see web page if it doesn't work)
Web: http://people.tribe.net/hayesstw
http://www.geocities.com/Athens/7783/
Charlie
"Steve Hayes" <haye...@hotmail.com> wrote in message
news:ipbds2dei67clg5v4...@4ax.com...
> On Sun, 04 Feb 2007 14:21:04 GMT, "Bob Jones" <rjo2...@bigpond.net.au>
> wrote:
>
>>G'day,
>>The Y2K was not a software problem (as such). It was a hardware problem in
>>that the onboard memory of early computers had enough memory assigned to
>>the
>>computer date function to handle ddmmyy. This meant that when the year
>>changed from 31/12/99 to 01/01/00 then all the programs that used the
>>computer time /date would "assume" that the year was 1900 instead of 2000.
>>The solution was not to upgrade your software but upgrade your hardware to
>>a
>>mother board that had the necessary amount of computer memory to handle a
>>4
>>digit year instead of the previous 2 digit year. There was very little Y2K
>>drama for the simple reason that we were given lots of warning (time wise)
>>and most people upgraded their hardware before 2000 which negated the
>>EOTWAWKI threat.
>
> Not so.
>
> Computers had enough memory to deal with it from the early 1980s, but
> short-sighted programmers still only allocated enough memory for two-digit
> years.
Being one of the short-sighted programmers referenced in your post, perhaps
you may want to cogitate upon a couple of issues related to that presumed
short-sightedness.
First, and as one who programmed mainframe computers from the mid 1960's, I
never considered that any program created in that time-frame would still be
operating in 5 years time let alone 35 years.
A bigger issue that I came across related to converting the history file of
transactions that had accumulated with a 'yy' format to a 'yyyy' format.
One's ability to remove an application system from an operational status for
the time necessary to convert the "master" file depended upon the importance
that the system had in the mind of the user. The higher the importance or
dependancy the less time one was given to convert the old system. One client
I was responsible for had a serious problem in that the system in question
was in use from 8 to 5, five days a week by in excess of 100 staff as a norm
and was expected to be available after hours until midnight from Monday to
Friday. When the revised system was ready for testing and conversion we were
told in no uncertain terms that the problem was ours, not theirs, and we
would have to find a method to correct the situation without taking the
operational system off-line for more than a week-end. Since the chances of
that happening were remote ( there were 100's of programs in the system and
some 50 to 75 files that would have to be converted) a different solution
was needed. The user also refused to run parallel systems until the bugs
were ironed out of the revised system.
IBM, I think it was, defined an algorithm that could be inserted in each
program that read the date that made some basic assumptions about whether
the 'yy' should have a '19' or a '20' placed in front of it. It worked and
the proper solution was put off for another day. So, in a number of
instances the problem is still there it is just more hidden. Perhaps the
system users should bear some responsibility for that problem.
mickg
> Not so.
>
> Computers had enough memory to deal with it from the early 1980s, but
> short-sighted programmers still only allocated enough memory for two-digit
> years.
>
> One of my favourite programs, which I use a lot for genealogy, has an
> automatic date entry which enters todays date as 5 February 1107, and I have
> to go back and correct it. At least it can calculate the date correctly,
> thoguht, unlike earlier versions of PAF, which report errors in the birth and
> death dates of anyone born or died after 31 Dec 1999
>
I suggest you do a little reading about the Software Development Process
which with some organizational variability has been in place for many
years, having evolved from other earlier development and design
processes. Also of course confusing end user software such as Genealogy
software with the commercial software used by large organizations, such
as banks, is comparing chalk and cheese.
Programmers do not design or specify what they produce but rather
produce to meet formerly specific requirements made and/or approved by
management usually on the basis of specifications from marketing (not to
be confused with sales).
Thus the issues which became apparent in the Y2K issue which was, put
quite simply a result of storing the year in dates as 2 digit numbers
rather than 4 digits came down to specification provided by the
Marketing/Management combination. People who are traditionally notably
short sighted, not being able to see beyond the bottom line of the
annual balance sheet.
MickG
Steve Hayes
>
>"Steve Hayes" <haye...@hotmail.com> wrote in message
>> Computers had enough memory to deal with it from the early 1980s, but
>> short-sighted programmers still only allocated enough memory for two-digit
>> years.
>
>Being one of the short-sighted programmers referenced in your post, perhaps
>you may want to cogitate upon a couple of issues related to that presumed
>short-sightedness.
>
>First, and as one who programmed mainframe computers from the mid 1960's, I
>never considered that any program created in that time-frame would still be
>operating in 5 years time let alone 35 years.
That in itself seems fairly shortsighted. Even if the program were replaced,
in many instances people would want to keep the data.
>A bigger issue that I came across related to converting the history file of
>transactions that had accumulated with a 'yy' format to a 'yyyy' format.
>One's ability to remove an application system from an operational status for
>the time necessary to convert the "master" file depended upon the importance
>that the system had in the mind of the user. The higher the importance or
>dependancy the less time one was given to convert the old system. One client
>I was responsible for had a serious problem in that the system in question
>was in use from 8 to 5, five days a week by in excess of 100 staff as a norm
>and was expected to be available after hours until midnight from Monday to
>Friday. When the revised system was ready for testing and conversion we were
>told in no uncertain terms that the problem was ours, not theirs, and we
>would have to find a method to correct the situation without taking the
>operational system off-line for more than a week-end. Since the chances of
>that happening were remote ( there were 100's of programs in the system and
>some 50 to 75 files that would have to be converted) a different solution
>was needed. The user also refused to run parallel systems until the bugs
>were ironed out of the revised system.
>
>IBM, I think it was, defined an algorithm that could be inserted in each
>program that read the date that made some basic assumptions about whether
>the 'yy' should have a '19' or a '20' placed in front of it. It worked and
>the proper solution was put off for another day. So, in a number of
>instances the problem is still there it is just more hidden. Perhaps the
>system users should bear some responsibility for that problem.
Genealogy programs have always needed to use dates that could be in more than
one century, so I was especially surprised that PAF did not take Y2K into
account.
--
Steve Hayes from Tshwane, South Africa
Web: http://hayesfam.bravehost.com/stevesig.htm
E-mail - see web page, or parse: shayes at dunelm full stop org full stop uk
joe.wakefield
> On Mon, 05 Feb 2007 23:35:05 -0500, mickg
> <mickg...@tampabay.rr.com> declaimed the following in
> soc.genealogy.computing:
>
>
>> processes. Also of course confusing end user software such as
>> Genealogy software with the commercial software used by large
>> organizations, such as banks, is comparing chalk and cheese.
>>
As are old bones! ;-)
--
Joe
Wakefield
Peter J Seymour
> On Sun, 04 Feb 2007 14:21:04 GMT, "Bob Jones" <rjo2...@bigpond.net.au> wrote:
>
>
>>G'day,
>>The Y2K was not a software problem (as such). It was a hardware problem in
>>that the onboard memory of early computers had enough memory assigned to the
>>computer date function to handle ddmmyy. This meant that when the year
>>changed from 31/12/99 to 01/01/00 then all the programs that used the
>>computer time /date would "assume" that the year was 1900 instead of 2000.
>>The solution was not to upgrade your software but upgrade your hardware to a
>>mother board that had the necessary amount of computer memory to handle a 4
>>digit year instead of the previous 2 digit year. There was very little Y2K
>>drama for the simple reason that we were given lots of warning (time wise)
>>and most people upgraded their hardware before 2000 which negated the
>>EOTWAWKI threat.
>
>
> Not so.
>
> Computers had enough memory to deal with it from the early 1980s, but
> short-sighted programmers still only allocated enough memory for two-digit
> years.
>
> One of my favourite programs, which I use a lot for genealogy, has an
> automatic date entry which enters todays date as 5 February 1107, and I have
> to go back and correct it. At least it can calculate the date correctly,
> thoguht, unlike earlier versions of PAF, which report errors in the birth and
> death dates of anyone born or died after 31 Dec 1999
>
software varies enormously between computer departments. This is the
real Y2K issue, not hardware or software constraints. One company I
worked for progressively designed out any Y2K problem from about 1980
onwards. Another, as 2000 approached, put in a systematic effort to
eradicate any
remaining problems. It all went without a hitch for these companies.
I do find it strange that there is apparently still at least one
genealogical program that can't cope.
Regards
Peter
Steve Hayes
wrote:
>On Tue, 06 Feb 2007 06:50:40 +0200, Steve Hayes
><haye...@hotmail.com> wrote:
>
>>On Tue, 06 Feb 2007 02:41:36 GMT, "Charlie" <ca...@shaw.ca> wrote:
>>
>>>
>>>"Steve Hayes" <haye...@hotmail.com> wrote in message
>>
>>>> Computers had enough memory to deal with it from the early 1980s, but
>>>> short-sighted programmers still only allocated enough memory for two-digit
>>>> years.
>>>
>>>Being one of the short-sighted programmers referenced in your post, perhaps
>>>you may want to cogitate upon a couple of issues related to that presumed
>>>short-sightedness.
>>>
>>>First, and as one who programmed mainframe computers from the mid 1960's, I
>>>never considered that any program created in that time-frame would still be
>>>operating in 5 years time let alone 35 years.
>>
>>That in itself seems fairly shortsighted. Even if the program were replaced,
>>in many instances people would want to keep the data.
>>
>
>When there is only 1.4K (yes 1.4K) of main (and no other) storage,
>every BCD character (not byte) matters. Fitting a program into 1.4K
>some 38 years before the millennium may have merited many descriptions
>but shortsighted was never one of them.
I was thinking more of programs developed AFTER the Sinclair ZX 80.
And what's going to happen to Unix programs after 2038?
joe.wakefield
> On Tue, 06 Feb 2007 06:50:40 +0200, Steve Hayes
> <haye...@hotmail.com> wrote:
>
>>
>>>
>>> "Steve Hayes" <haye...@hotmail.com> wrote in message
>>
>>>> Computers had enough memory to deal with it from the early 1980s,
>>>> but short-sighted programmers still only allocated enough memory
>>>> for two-digit years.
>>>
>>> Being one of the short-sighted programmers referenced in your post,
>>> perhaps you may want to cogitate upon a couple of issues related to
>>> that presumed short-sightedness.
>>>
>>> First, and as one who programmed mainframe computers from the mid
>>> 1960's, I never considered that any program created in that
>>> time-frame would still be operating in 5 years time let alone 35
>>> years.
>>
>> That in itself seems fairly shortsighted. Even if the program were
>> replaced, in many instances people would want to keep the data.
>>
>
> every BCD character (not byte) matters. Fitting a program into 1.4K
> some 38 years before the millennium may have merited many descriptions
> but shortsighted was never one of them.
>
> brightside S9
Indeed, my TRS-80 Pocket Computer (bought in 1981 and still working) has
1424 byte memory. All programs are in basic. You learn to be very economical
with what to display when showing results.
--
Joe
Wakefield
Steve Hayes
All of which is not really relevant, since we are talking about genealogy and
genealogy software here.
Perhaps, however, PAF was specified by a marketing department.
John Cartmell
Charlie <ca...@shaw.ca> wrote:
> Being one of the short-sighted programmers referenced in your post, perhaps
> you may want to cogitate upon a couple of issues related to that presumed
> short-sightedness.
> First, and as one who programmed mainframe computers from the mid 1960's, I
> never considered that any program created in that time-frame would still be
> operating in 5 years time let alone 35 years.
I certainly don't quibble about programmers from the 60s. It's the specific
Windows problems that were still being ignored by Microsoft in the 90s that I
find unacceptable. In general it wasn't a 'computer' problem - rather a legacy
(ie 60s and 70s computers) problem - which was understandable - and a
Microsoft problem - which was neither understandable nor forgivable. It would
have been appropriate for users to let Microsoft go to the wall for that
'mistake'; they were showered with money instead.
--
John
Allen
You apparently never programmed for a bank. Mortgage loan maturities 40
to 50 years away (on commercial properties) and instalment loans with
eight-year payout schedules highlighted the Y2K issue from the start. My
bank didn't have to worry about this in 1962, when we first started to
pragram for an IBM 1401 with a whopping 4K of memory, but by 1966 and
the arrival of our first IBM 360 Mod 30, with a gigantic 16K, we were
getting into mortgage loan processing and all dates were expressed as
yyyy. Also, the time constraints you fretted about were SOP in banking;
three-day weekends were a programmer's dream, as they had an extra whole
day for testing and tweaking. I wasn't officially a programmer, but a
banker who knew as much about computers as most of our programmers did,
to the extent that I sometimes helped debug IBM assembly language
programs. I was in charge of converting our Trust Department from a
manual posting system back in the earlyish 1970s. We scheduled two full
weekends for the conversion, but signed off fully converted and tested
at 4:00 PM on the first Saturday; this was the result of meticulous
planning, testing and before-hand data conversion. I handled a fairly
large number of conversions and on only one did I miss the established
deadline, because I was in the hospital undergoing surgery. The big
secret to successful data processing operations in organizations is
simply communication and mutual understanding. I used to tell people
that I was tri-lingual, that I spoke Banker, Programmer, and
English--three different languages.
Allen
Richard van Schaik
> Steve Hayes wrote:
>> At least it can calculate the date correctly,
>> thoguht, unlike earlier versions of PAF, which report errors in the
>> birth and
>> death dates of anyone born or died after 31 Dec 1999
> I do find it strange that there is apparently still at least one
> genealogical program that can't cope.
An older version of a genealogical program. My version does not have any
problem with a death date on 29 Sep 2006 or a marriage date on 20 Feb 2002.
Richard
--
Richard van Schaik
f.m.a.vans...@THISwanadoo.nl
http://www.fmavanschaik.nl/
Robert M. Riches Jr.
>
> I was thinking more of programs developed AFTER the Sinclair ZX 80.
>
> And what's going to happen to Unix programs after 2038?
How about Y10K, when four digits aren't enough? Now, who's
shortsighted? 1/2 :-)
--
Robert Riches
spamt...@verizon.net
(Yes, that is one of my email addresses.)
Allen
> On 2007-02-06, Steve Hayes <haye...@hotmail.com> wrote:
>
>>I was thinking more of programs developed AFTER the Sinclair ZX 80.
>>
>>And what's going to happen to Unix programs after 2038?
>
>
> How about Y10K, when four digits aren't enough? Now, who's
> shortsighted? 1/2 :-)
>
I'll get back with next year on that.
Allen
Everett M. Greene
> You apparently never programmed for a bank. Mortgage loan maturities 40
> to 50 years away (on commercial properties) and instalment loans with
> eight-year payout schedules highlighted the Y2K issue from the start. My
> bank didn't have to worry about this in 1962, when we first started to
> pragram for an IBM 1401 with a whopping 4K of memory, but by 1966 and
> the arrival of our first IBM 360 Mod 30, with a gigantic 16K, we were
> getting into mortgage loan processing and all dates were expressed as
> yyyy. Also, the time constraints you fretted about were SOP in banking;
> three-day weekends were a programmer's dream, as they had an extra whole
> day for testing and tweaking. I wasn't officially a programmer, but a
> banker who knew as much about computers as most of our programmers did,
> to the extent that I sometimes helped debug IBM assembly language
> programs. I was in charge of converting our Trust Department from a
> manual posting system back in the earlyish 1970s. We scheduled two full
> weekends for the conversion, but signed off fully converted and tested
> at 4:00 PM on the first Saturday; this was the result of meticulous
> planning, testing and before-hand data conversion. I handled a fairly
> large number of conversions and on only one did I miss the established
> deadline, because I was in the hospital undergoing surgery. The big
> secret to successful data processing operations in organizations is
> simply communication and mutual understanding. I used to tell people
> that I was tri-lingual, that I spoke Banker, Programmer, and
> English--three different languages.
Taking your description at face value, you are to be
congratulated on work well done.
I thought if one worked in commercial DP, one had to speak
COBOL as well.
[Now about some paragraph breaks in your writing...]
Allen
programmers just couldn't find the time (actually inclination) to do, so
I wrote one in COBOL D. It involved a very large reference table, and
native COBOL D supported only start-at-the-top, go one-by-one-to the
bottom: I wasn't about to write an assembler routine for a binary
search, and most of the hits were on the bottom end of the table. It was
run several times a day and brought the 370/145 that it ran on to its
knees, preempting everything else that was trying to run. I thought that
it would shame our programming staff into writing a proper one, but no!
It was run for three years. I H-A-T-E C-O-B-O-L!
Allen
Ron
>
> First, and as one who programmed mainframe computers from the mid 1960's, I
> never considered that any program created in that time-frame would still be
> operating in 5 years time let alone 35 years.
In early 1970s I had a monthly service billing program with one digit
for anniversary year - it assumed any thing 5-9 was 196x and 0-4 was
197x. Of course by 1975 we had to change it BUT main frame we had was
probably a bit short of capacity compared to machine on which I write this
>
> IBM, I think it was, defined an algorithm that could be inserted in each
> program that read the date that made some basic assumptions about whether
> the 'yy' should have a '19' or a '20' placed in front of it. It worked and
> the proper solution was put off for another day. So, in a number of
> instances the problem is still there it is just more hidden. Perhaps the
> system users should bear some responsibility for that problem.
Some pre2000 programs would have had 2 digits years with something like
my one digit year - anything 66 plus was 19xx and hence 0-65 would be 20xx
>
>> One of my favourite programs, which I use a lot for genealogy, has an
>> automatic date entry which enters todays date as 5 February 1107, and I
>> have
>> to go back and correct it.
Amazing how could genealogy software employ any algorithm for date - it
should allow for full millennium input (ok what about BC)
Calendar programs are very complex on dates - having to allow
calculations for Easter etc- and much the same should be in genealogy
program
--
Ron Lankshear - Sydney Aust (from London- Shepherds Bush & Chiswick)
http://freepages.rootsweb.com/~lankshear/
Charlie
> On Sun, 04 Feb 2007 14:21:04 GMT, "Bob Jones" <rjo2...@bigpond.net.au>
> wrote:
>
>>G'day,
>>The Y2K was not a software problem (as such). It was a hardware problem in
>>that the onboard memory of early computers had enough memory assigned to
>>the
>>computer date function to handle ddmmyy. This meant that when the year
>>changed from 31/12/99 to 01/01/00 then all the programs that used the
>>computer time /date would "assume" that the year was 1900 instead of 2000.
>>The solution was not to upgrade your software but upgrade your hardware to
>>a
>>mother board that had the necessary amount of computer memory to handle a
>>4
>>digit year instead of the previous 2 digit year. There was very little Y2K
>>drama for the simple reason that we were given lots of warning (time wise)
>>and most people upgraded their hardware before 2000 which negated the
>>EOTWAWKI threat.
>
> Not so.
>
> Computers had enough memory to deal with it from the early 1980s, but
> short-sighted programmers still only allocated enough memory for two-digit
> years.
Being one of the short-sighted programmers referenced in your post, perhaps
you may want to cogitate upon a couple of issues related to that presumed
short-sightedness.
First, and as one who programmed mainframe computers from the mid 1960's, I
never considered that any program created in that time-frame would still be
operating in 5 years time let alone 35 years.
A bigger issue that I came across related to converting the history file of
transactions that had accumulated with a 'yy' format to a 'yyyy' format.
One's ability to remove an application system from an operational status for
the time necessary to convert the "master" file depended upon the importance
that the system had in the mind of the user. The higher the importance or
dependancy the less time one was given to convert the old system. One client
I was responsible for had a serious problem in that the system in question
was in use from 8 to 5, five days a week by in excess of 100 staff as a norm
and was expected to be available after hours until midnight from Monday to
Friday. When the revised system was ready for testing and conversion we were
told in no uncertain terms that the problem was ours, not theirs, and we
would have to find a method to correct the situation without taking the
operational system off-line for more than a week-end. Since the chances of
that happening were remote ( there were 100's of programs in the system and
some 50 to 75 files that would have to be converted) a different solution
was needed. The user also refused to run parallel systems until the bugs
were ironed out of the revised system.
IBM, I think it was, defined an algorithm that could be inserted in each
program that read the date that made some basic assumptions about whether
the 'yy' should have a '19' or a '20' placed in front of it. It worked and
the proper solution was put off for another day. So, in a number of
instances the problem is still there it is just more hidden. Perhaps the
system users should bear some responsibility for that problem.
The real source of the "problem" is that a number of computerized systems
were spawned from the
days of the 80 column punch card where the use of non-essential columns was
not approved. Therefore,
those systems started off with 2-digit years and the problems became far
more then just adding two "columns" to the year field.
Dale DePriest
Steve Hayes wrote:
> On Tue, 06 Feb 2007 09:12:55 +0000, brightside@replyto_addy_is_not.invalid
> wrote:
>
>> On Tue, 06 Feb 2007 06:50:40 +0200, Steve Hayes
>> <haye...@hotmail.com> wrote:
>>
>>> On Tue, 06 Feb 2007 02:41:36 GMT, "Charlie" <ca...@shaw.ca> wrote:
>>>
>>>> "Steve Hayes" <haye...@hotmail.com> wrote in message
>>>>> Computers had enough memory to deal with it from the early 1980s, but
>>>>> short-sighted programmers still only allocated enough memory for two-digit
>>>>> years.
>>>> Being one of the short-sighted programmers referenced in your post, perhaps
>>>> you may want to cogitate upon a couple of issues related to that presumed
>>>> short-sightedness.
>>>>
>>>> First, and as one who programmed mainframe computers from the mid 1960's, I
>>>> never considered that any program created in that time-frame would still be
>>>> operating in 5 years time let alone 35 years.
>>> That in itself seems fairly shortsighted. Even if the program were replaced,
>>> in many instances people would want to keep the data.
>>>
>> When there is only 1.4K (yes 1.4K) of main (and no other) storage,
>> every BCD character (not byte) matters. Fitting a program into 1.4K
>> some 38 years before the millennium may have merited many descriptions
>> but shortsighted was never one of them.
>
> I was thinking more of programs developed AFTER the Sinclair ZX 80.
>
> And what's going to happen to Unix programs after 2038?
>
>
Well there were lots of machines older than that. A surprising number of
programs were written in Cobol (even today) and the language itself
encourage a 2 digit year. Initially that was all it even supported, I
believe.
Unix will be saved by 64 bit machines. Note that Unix and for that
matter Windows uses a clock that counts seconds from an arbitrary point
and the 32 bit number used to store that value in unix will overflow in
2038. Windows started later so the overflow with be further in the future.
Dale
--
_ _ Dale DePriest
/`) _ // http://users.cwnet.com/dalede
o/_/ (_(_X_(` For GPS and GPS/PDAs
Dale DePriest
Ron wrote:
>
> Amazing how could genealogy software employ any algorithm for date - it
> should allow for full millennium input (ok what about BC)
>
> Calendar programs are very complex on dates - having to allow
> calculations for Easter etc- and much the same should be in genealogy
> program
My program does permit BC dates although I do not believe GEDCOM defines
a date in this range.
David H Wild
Dale DePriest <Da...@gpsinformation.het> wrote:
> > And what's going to happen to Unix programs after 2038?
> >
> >
> Well there were lots of machines older than that. A surprising number of
> programs were written in Cobol (even today) and the language itself
> encourage a 2 digit year. Initially that was all it even supported, I
> believe.
> Unix will be saved by 64 bit machines. Note that Unix and for that
> matter Windows uses a clock that counts seconds from an arbitrary point
> and the 32 bit number used to store that value in unix will overflow in
> 2038. Windows started later so the overflow with be further in the
> future.
There is a problem with the overflow only when the program is taking dates
from the machine. For many programs what is being recorded is "historic"
dates - such as when someone started work or moved house. In theses cases
all dates will be from data input, and this is where many programs fell
down by working only with two-digit years.
--
David Wild using RISC OS on broadband
T.M. Sommers
> On Tue, 06 Feb 2007 09:12:55 +0000, brightside@replyto_addy_is_not.invalid
>
By that time, time_t will be 64 bits. The only problems will be
with programs that assume time_t is 32 bits, and with programs
that store time_ts. The former should be fixed now. The latter
category would include system accounting software and
filesystems. However, there is no need to rush into fixing
either of these. It is not likely, for instance, that any
filesystem existing today will still be around in 30 years.
--
Thomas M. Sommers -- t...@nj.net -- AB2SB
Steve Hayes
wrote:
I'm sure there were lots of machines older than that, but how many of them had
genealogy programs available for them?
One of the earliest genealogy programs I knew of was Roots, which ran entirely
in memory, and so was fairly limited in what it could accomplish. I had to fit
my family in by usung four separate files.
>
>Unix will be saved by 64 bit machines. Note that Unix and for that
>matter Windows uses a clock that counts seconds from an arbitrary point
>and the 32 bit number used to store that value in unix will overflow in
>2038. Windows started later so the overflow with be further in the future.
>
>Dale
--
Steve Hayes
I am using a genealogy program that I started using 20 years ago.
T.M. Sommers
> On Wed, 07 Feb 2007 13:43:23 -0500, "T.M. Sommers" <t...@nj.net> wrote:
>>Steve Hayes wrote:
>>
>>>On Tue, 06 Feb 2007 09:12:55 +0000, brightside@replyto_addy_is_not.invalid
>>>
>>>And what's going to happen to Unix programs after 2038?
>>
>>By that time, time_t will be 64 bits. The only problems will be
>>with programs that assume time_t is 32 bits, and with programs
>>that store time_ts. The former should be fixed now. The latter
>>category would include system accounting software and
>>filesystems. However, there is no need to rush into fixing
>>either of these. It is not likely, for instance, that any
>>filesystem existing today will still be around in 30 years.
>
> I am using a genealogy program that I started using 20 years ago.
Probably not on the same hard drive, though.
Steve Hayes
>Steve Hayes wrote:
>> I am using a genealogy program that I started using 20 years ago.
>
>Probably not on the same hard drive, though.
No.
It started off on a 20 Meg drive with a faulty controller, and I had to keep
replacing records that got corrupted. When upgraded to a 30 Meg RLL drive,
that problem disappeared.