| We need Your Support. Make a Donation now! or |  |
|
||||||||||||||||||||||||||||||||||||||||||||||
|
To make a long story short, the Amiga in general does not suffer from the Year 2000 problem in the context known to the PC world. However, the Amiga faces three distinct date problems and a single, specific Year 2000 problem with limited scope which will be described below. 1. Scope of this document The following text refers to Amiga desktop computers built between 1986 and 1997 and only covers computer hardware configurations designed and built by Commodore-Amiga, Inc. This specifically excludes 3rd party hardware extensions, such as the Microbotics "StarBoard" which among other features offered a battery backed up clock, but it includes Amiga computers built by Amiga Technologies GmbH and Amiga, Inc. 2. How the Amiga handles date and time The Amiga operating system has always followed the Unix model in measuring time as the number of seconds that have elapsed since a fixed point of time. Under AmigaOS that fixed point of time (also known as `epoch') is 00:00:00 of January 1, 1978 (Unix uses 00:00:00 GMT, January 1, 1970). The operating system manages time and date through a central component known as timer.device. This component reads and stores date and time information using a data structure known as timeval which, in `C' language notation, is shown below:
In this context an ULONG refers to an unsigned 32-bit quantity. The tv_secs structure member holds the number of seconds that have elapsed since the AmigaOS epoch and the tv_micro member denotes the number of microseconds (10-9th part of a second) that have elapsed since the last second has passed. b 2.1 The AmigaDOS date and time handling is special "AmigaDOS" and "AmigaOS" are not two names for the same thing. Exactly the opposite is true: AmigaDOS is (in a nutshell) the name of the AmigaOS layer which implements filing systems and their actions, the command line interpreter and which handles loading and relocation of executable binary files. AmigaDOS is more or less a port of the Cambridge University Tripos 32-bit kernel. It has its own peculiar data structures, including its own version of the timeval structure described above. The AmigaDOS flavour is known as DateStamp, as shown below:
In this context a LONG refers to a signed 32-bit quantity. The ds_Days member contains the number of days (each day consists of exactly 24 hours) that have passed since the AmigaOS epoch. The ds_Minute member denotes the number of minutes that have passed since midnight (00:00:00) of the given day and the ds_Tick member contains the number of "ticks" that have passed since the last minute. A minute consist of 3,000 "ticks", i.e. there are 50 ticks in a second. AmigaDOS uses DateStamps to describe file and volume creation dates, and all shell commands follow the same model, i.e. if the system date is set through the shell Date command, it will calculate time and date in DateStamp format. 2.2 Local time vs GMT The Amiga operating system never knew the concept of local and global time. While the AmigaOS 2.1 update (1992) introduced a locale preferences editor that allowed for the time zone to be selected, the operating system itself never put this feature to use or encouraged application software developers to use it. One might argue that with this background, the AmigaOS was always tuned to local time. 2.3 How the Amiga maintains its system time The early Amiga computer models did not support a battery backed up real time clock that would keep on ticking and maintaining local time even until after the machine was switched off. For example, the first Amiga computer ever (later christened the Amiga 1000) did not offer a battery backed up clock. For the Amiga 500 the battery backed up clock was an extra hardware feature one had to buy separately with a memory expansion. The Amiga 2000 and (with the exception of the Amiga 600, 500+ and 1200 models) all models to follow did feature a built-in battery backed up clock. On machines without battery backed up clocks, the Amiga sets its system time according to the modification date of the boot volume. In other words, the point of time the last file was modified or created on a disk would determine the system time. As this was by no means accurate, the AmigaOS boot process would suggest and prompt you to adjust the system date once the system had booted (as pictured below).  If the system starts up without being able to set its system time, it defaults to 00:00:00 January 1, 1978. 3. Setting and reading the time The Amiga offers both a command line interface and a graphical user interface. Both went through a number of changes over the years as will be described below. 3.1 The command line interface There are two shell commands that deal with the system date, these being SetClock and Date. The Date command is for reading and setting the current system date whereas the SetClock command deals with the battery backed up clock, it reads and stores the current system time from/in it. The Date command is of particular interest due to the human readable date format it uses by default. Today you might invoke the Date command and receive the following output:
As one can see, the year number is limited to two digits only. Even if a different locale is used (e.g. french), the year will always be displayed with its two last decimals only. Luckily, this numbering is consistent with the following rule:
All versions of the AmigaDOS Date command (version 1.1 through version 37.1) display and parse the data format in the same fashion. They behave consistently and predictably throughout all Amiga operating system revisions. 3.2 The graphical user interface The system time is set through the preferences editor which in AmigaOS versions 1.0-1.3 used to be a single, monolithic program as pictured below:  With the introduction of AmigaOS 2.0, the time preferences editor was moved into a single program named Time as pictured below:  When the AmigaOS 2.1 update was released, the time preferences editor was revised, as can be seen below:  4. The problems As far as is known today, the Amiga faces four date problems. Two are design problems caused by numeric overflow, one is caused by hardware limitations and one is a real bug that will strike in the year 2000. 4.1 Negative time As was outlined above, the Amiga measures time in seconds. As it turns out, the number of seconds to accumulate until 19 January, 2046, 03:14:07 will form the largest value a signed 32-bit integer number will hold. This is not a problem for the time keeping module (timer.device), but application software and other operating system components which treat the number of seconds as a signed quantity will get into trouble one second later: the number of seconds will rise to 2,147,483,648 which in two's complement format represents the negative number -2,147,483,648. AmigaDOS, which always treats time as a signed quantity, will consider this date to be invalid because it is negative. Worse, the ROM date conversion routines exhibit a bug which, once the date is later than 19 January, 2046, 03:14:07, causes all subsequent date operations to be inaccurate. The immediate effect this has is that calculations on dates can be off by more than two years. This behaviour is consistent through all AmigaOS versions. A fix is not available yet, but research is in progress to investigate whether this bug may be fixed by updating several AmigaOS modules (locale.library, dos.library). After all, this bug is "just" a side-effect of treating an unsigned quantity as signed. 4.2 Time rolling over An unsigned 32-bit integer can hold a maximum value of 4,294,967,295. When the Amiga has accumulated that many seconds, it will be 7 February, 2114, 06:28:15. One second later the seconds counter will roll over and restart at 0. In other words, on 7 February, 2114, 06:28:16 the Amiga will believe that it is midnight on 1 January, 1978. No fix for this problem is available yet. 4.3 The battery backed up clock can count only to 99 Amiga computers that feature a battery backed up real time clock use one of two different hardware designs: either the Oki MSM6242RS (A500, A2000) or the Ricoh RP5C01 (A3000, A1200, A4000) chip. As is common with clock chips of that type, the year counter is implemented as a two digit BCD number. Once it reaches the year 99, the counter will roll over and start again with 00. Starting with Amiga operating system version 2.0, the boot process will read the battery backed up clock time and set the system time accordingly. This takes place every time the Amiga is reset. Because the year number covers only two digits, the same algorithm as used by the AmigaDOS Date command is employed. The consequence this has is that the Amiga system date set at system startup time will always be in the range 1978..2077. While the system clock will keep on ticking beyond 31 December, 2077 a system reset will set the clock back to 1 January, 1978. No fix for this problem is available yet. 4.4 SetClock stops working in the year 2000 The SetClock program shipped with the Amiga Workbench disk revisions 1.2 and 1.3 exhibits a bug which causes it to miscalculate the battery backed up clock time starting with the year 2000. It is accurate only for the years 1978..1999. Once the year counter rolls over to 00, SetClock will believe that the year is 1978 until the year 2079 is reached; that's when it will believe that the year is 1979 -- which is not necessarily an improvement. Please note that only the SetClock program found on the AmigaOS 1.2 and 1.3 Workbench disks suffers from this problem. Several versions of this program were distributed, each between 4,000 and 7,000 bytes in size. To tell whether you have a version that works or not, check the file size; if it is less than 1,000 bytes in size you will probably have the properly working version. If it is larger than 4,000 bytes, you probably have the faulty version. A fix for this problem is provided in this archive. Download it and unpack it, then read the enclosed "SetClock_ReadMe" file.
|
|||||||||||||||||||||||||||||||||||||||||||||
