Year 2000 Fix

Y2KFix ------ The problem ----------- On a Master 128 with OS 3.2, the date (as reported by *TIME, for example) will wrap around to 1st January 1900 at midnight on 1st January 2000. This may also occur with the later OS 3.5 and the various third-party real time clocks available for the other 8-bit Acorn machines. (I'm not even close to being an expert, but in case this 'fix' misleads anyone, the 'real' year 2000 problem is much more complicated.) For the impatient... -------------------- The rest of this documentation has an unfortunate tendency to interweave technical and non-technical information, so please don't be put off reading it if parts seem beyond you. In brief, though: To 'fix' the year 2000 problem, just *RUN Y2KFix before any program which uses the date. (You'll need to do this again if you press BREAK.) To see that the problem has been fixed, try the following (sorry if this is patronising): Type *RUN Y2KFix, then *TIME to see that Y2KFix doesn't interfere with dates before 2000 (this isn't strictly true; see below if you're interested.) Press BREAK to make sure Y2KFix isn't installed Type TIME$="Fri,31 Dec 1999.23:59:00" Type *TIME to see that the time and date have been set correctly Wait for about a minute Type *TIME to see that the year is now wrong; it says 1900 instead of 2000. Type *RUN Y2KFix, then *TIME to see that the year is now right. Press BREAK to make sure Y2KFix isn't installed Type *TIME to see that the year is now wrong again. Type *RUN Y2KFix, then *TIME to see that the year is now right. (This shows that you don't have to worry about loading Y2KFix all the time, only when you need it. The date and time will continue to be updated correctly even if it's not loaded, it's just that the date will be displayed wrongly.) What Y2KFix does ---------------- This simple program intercepts the OSWORD vector and traps the calls to read the current time as a string and to convert a BCD time to a string. The OS deals with the call as usual, then if the year is earlier than 1970, the 19 in the year is changed to a 20 before returning to the program which issued the OSWORD call. The result of this is that, to some extent, the real time clock works correctly from 1970 to 2069 instead of 1900 to 1999. No special action is needed when setting the clock, as the OS just seems to ignore the century part of the year. It doesn't check that the day of the week is correct, so it doesn't matter that 1st January 1900 was a Monday while 1st January 2000 is a Saturday. Although 1900 wasn't a leap year, the RTC and/or OS treat it as though it was, so the fact that 2000 is a leap year doesn't cause problems. The OSWORD call to read the current time in BCD format doesn't return the century part of the year. As a result, this program is of no use with any software which reads the time in BCD format and uses that directly instead of having the OS convert it to a time string. If this doesn't make any sense, don't worry; it just means that programs which read the date from the real time clock and don't assume the century will be 19 will work correctly even after 1999. (It is not necessarily a sign of a badly written program to assume that the century will be 19, at least not on the 8-bit Acorn machines, as one method of reading the date doesn't return a century year; this is what the previous paragraph is about.) It's all a bit cosmetic really, but it just might be useful to someone and it kept me amused for an hour or two while I wrote it. How to use it ------------- An assembled version of the machine code is supplied as Y2KFix. This occupies memory from &A80 to &AFF, although the first part of the code is only used for initialisation and can be overwritten once it has been run. If you want to store the code somewhere else, load Y2KFixS, alter the value of dest% in PROCinit and RUN it to assemble a new copy of Y2KFix. You will need BASIC 2 or later to run Y2KFixS as it uses offset assembly. This is obviously not a problem for Master 128 owners, but it may matter to the hypothetical owner of a BBC B with BASIC 1 and a real time clock upgrade. If anyone has this problem please contact me and I'll see if I can do anything to help. Once you have a suitable copy of Y2KFix, you can simply *RUN Y2KFix to use it. This should probably be done in the !Boot file of the disc containing the program which needs it. Note that the code does not remain in place over a BREAK, let alone a CTRL-BREAK. This could be fixed quite easily, and if you feel this is necessary and can't do it for yourself then please contact me. I haven't done it as standard because it would increase the amount of memory used slightly and prevent any other utilities from remaining installed over a BREAK or CTRL-BREAK. How I tested it --------------- I tested Y2KFix using an extremely simple program, TestY2K, which sets the date and time to just before midnight on 31st December 1999 and then makes each day pass fairly quickly by repeatedly setting the time to just before midnight and waiting for the time to wrap around at midnight. If you want to try this yourself, please note that it (fairly obviously) destroys the existing time and date, which will have to be manually reset afterwards. Writing TestY2K revealed an interesting quirk in the RTC and/or OS. Try changing the TIME$="23:59:57" line to read TIME$="23:59:58" or TIME$="23:59:59" and run the program again. (Both have a different effect on my Master.) I thought this was a fault in my code at first, and after switching off and on didn't cure the problem I started to wonder if I'd damaged the RTC somehow. I tried TestY2K on a RISC OS 2 Archimedes 310 (with the intention of comparing the output of a long run against that from a Master 128 using Y2KFix, to see if it worked correctly in the long term) and even with a few minutes' fiddling I couldn't get the A310 to run it properly. I haven't experimented further or tried any other Acorn machines/OSs yet; if anyone is inspired to look into this then I'd be interested in hearing about it. Copyright --------- Y2KFix is genuinely public domain software. You can do anything you like with it - sell it for profit, give it away, modify it and release your own version, etc. It would be nice if you let me know what you do with it, but having placed it in the public domain I have no right to insist on this. Contacting me ------------- Bug reports or suggestions for improvements are welcome, but I can't promise to do anything with them. You can contact me through the 8-Bit Software messaging system (user 15A), or write to me directly: Steven Flintham 6 Laythorpe Avenue Skegness Lincolnshire PE25 3BX (no 'phone calls please). If you want a reply or the return of any discs you send, please enclose a SAE. (I can handle any standard Acorn disc format.)