Date   : Mon, 27 Sep 1999 01:04:40 +0100
From   : jgh@... (Jonathan Graham Harston)
Subject: Y2K problem

> John Simpson wrote:
> > - Exactly what happens to Masters in the Year 2000? Does the date just
> > go wrong or does the computer stop working entirely?
 
On Tue, 21 Sep 1999, Chris Richardson wrote:
> Have a look at Robert Sprowson's description of the problem and fix
> http://www-users.york.ac.uk/~rps102/bbc/doomsday.htm
 
Andrew Benham <adsb@...> wrote:
> Or the fix on my web pages:
> http://members.tripod.com/~g8fsl/bbc/
 
The main problem in reading the current date is sloppy programming. 
Here's a post I made to csa.programmer a couple of months ago discussing
it, and showing a standard way of reading the current date that will be
consistantly correct in returning the date.
 
----8<----
::: Area #157 (comp.sys.acorn.programmer)
Message: #42824 (Read 1 time, has 0 replies, 3456 bytes)
Date   : Mon Jul 26 01:07:31 1999
>From   : Jonathan Graham Harston of fidonet#2:254/27
Subject: Subject: Re: RISC OS4 - Millennium Compliance (reply to #42706)
 
kade_fh@... wrote:
> Gareth J Dykes wrote:
> > RISCOS Ltd Millennium compliance statement
> > ------------------------------------------
> [snip]
> > In order to comply with this, the following calls have changed slightly
> > in their operation:
> >    OS_Word 14,1
> >       This call returns the current time as a set of BCD values. You
should
> >       treat the year in the following manner :
> >         if year < 66 then
> >           fullyear = 2000 + year
> >         else
> >           fullyear = 1900 + year
> This will only work until 2065. If a full year value is required,
> shouldn't the call's return values be used in conjunction with the CMOS
> RAM century value to calculate the full year?
> Of course, I agree that if you want to obtain a full year value, OS_Word
> 14,1 is not the right call to be using. But you guys did bring it up...
> :-)
 
Not so much a change in the call, more a "more explicit declaration of how
the call should be used".
 
Osword14 has never been guaranteed to correctly return the year, most
explicitly because Osword14,1 only returns a two-digit year, so programs
have always needed to process the returned data before using it.
 
Some systems don't provide Osword14, so the returned data has to be
checked to see if there was returned data.
 
Some systems provide Osword14, but don't have a RTC, and return a default
string, which have to be checked for.
 
Some systems fetch the time&date from a server, but mess up, mixing the
year and date data, so these have to be checked for.  (Some systems
thought that 1997 was 1981.)
 
As NetFS dates represent the year as a 7-bit offset from 1981, that has
always been the recommended pivot point, so code would do something like:
if year<81 then fullyear 00+year else year=1900+year
 
When manipulating the date as a string, it is easier to use 1980 as the
pivot point with almost the same result, as it involves checking a single
character, so making code do something like:
if year[2]<'8' then year[0..1]="20" else year[0..1]="19"
 
So, IF using Osword14 to find the date
    THEN process the result before using it
 
The following is the function I use when I need to compatibly use Osword
14 to read the time&date as a string:
 
    DIM ctrl% 30
 
    DEFFNtime:LOCALX%,Y%,A%:X%=ctrl%
    Y%=X%DIV256:?X%=0:A%=14:CALL&FFF1:IF?X%=0:=""
    X%?25=13:X%?15=13:A%=VALMID$($X%,5,2)DIV32
    $(X%+11)=STR$(VAL$(X%+11)+16*A%-100*(VAL$(X%+11)<1981))
    IFA%:X%?6=13:$(X%+4)=RIGHT$("0"+STR$(VAL$(X%+4)-32),2):X%?6=32
    X%?15=46:=$X%
 
This reads the RTC regardless of what machine it is running on, and will
correct for years after 1996 and 1999, or return a null string if no time
is available.  The 'Acorn Era' is defined as starting in 1981, so the
century range is 1981-2080.
 
See also:
http://mdfs.net/Docs/ManPages/O/2OSWORD14
http://mdfs.net/Docs/ManPages/T/3Time
 
----8<----
 
The Master does not know what day of the week a certain date is, it
depends on being told the correct day when the date is set.  If you do
TIME$="Mon,26 Sep 1999", it does not know that it should be SUNday, but
continues incrementing the day correctly.  So, even though 1-Jan-1900 is a
different day from 1-Jan-2000, as long as the Master knows that
31-Dec-1999 is a FRIday, the day is simply incremented to SATurday, even
though raw use of Osword14 returns Sat,01 Jan 1900.  Using FNtime
correctly returns Sat,01 Jan 2000.  This also means that 29-Feb-2000 is
correctly returned, as the Master has no concept of century leap years. 
Even though internally the Master will think it's 29-Feb-1900 (which does
not exist), processing the date correctly gives 29-Feb-2000, which does
exist.
 
-- 
J.G.Harston (JGH BBC PD Library) 70 Camm Street, Walkley, SHEFFIELD S6 3TR
jgh@...                - Running on BBCs & Masters with SJ MDFS FileServer
            Z80+6502/CoPro+Tubes/Econet+SJ -- http://mdfs.net/