Amiga Unix Wiki

Because AmigaOS just isn't obscure enough today!

User Tools

Site Tools


Amix & Y2K

The built-in setclk utility is not Y2K compatible and it will complain about “date: bad conversion” on boot if the computer has RTC and/or a date of >2000 is entered.

A patched version can be downloaded here. Overwrite the original version (in /etc, /sbin, /usr/amiga/bin and /usr/amiga/src/cmd/setclk) with the newer one and you should no longer see the 'bad conversion' errors.

The discussion that led to the patched setclk utility is presented below. Thanks to Failure, Piru and a_petri on in 2007.


The bug was in sscanf() using %02d for the year. The year is 3 digits with years 2000++ so only first two first digits were parsed (year ended up 10 instead of 106). Also various buffers had to be extended to accommodate the extra char so no buffer overflow will occur.

However, if date can't grock it (which might well be the case), /usr/bin/date itself has to be fixed aswell (or if it handles < 70 year by adding 100, the parsed date has to be adjusted with 'if (year > 99) year -= 100;').

If you find the patch above useful please feel free to use it as you wish. I hereby place it in public domain.

Now assuming /usr/bin/date can handle 3 digit date (for example: 02111032106 that is: feb 11th 10:32 1900+106 = 2006), here is a fix:
--- setclk.c-orig Sat Feb 11 02:48:57 2006
+++ setclk.c Sat Feb 11 10:41:14 2006
@@ -51,7 +51,7 @@
     if (!strcmp(*argv, &quot;getclk&quot;))
- char buffer[11];
+ char buffer[12];
  retval = read_clock(buffer);
@@ -80,7 +80,7 @@
     if (argc == 1)
  time_t thetime = read_from_clock_device();
- char buffer[BUFSIZ*2], tmpbuf[sizeof(&quot;MMDDhhmmYY&quot;)];
+ char buffer[BUFSIZ*2], tmpbuf[sizeof(&quot;MMDDhhmmYYY&quot;)];
  ** Set the system time to what the hardware thinks is correct.
@@ -138,7 +138,7 @@
     if (set_clock)
- char buffer[11];
+ char buffer[12];
  struct tm *tm;
  time_t thetime;
@@ -175,7 +175,7 @@
     if (display_clock)
- char buffer[11];
+ char buffer[12];
  retval = read_clock(buffer);
@@ -299,7 +299,7 @@
  return FALSE;
-    if (sscanf(buffer, &quot;%02d%02d%02d%02d%02d&quot;, &month, &days, &hours, &mins,
+    if (sscanf(buffer, &quot;%02d%02d%02d%02d%03d&quot;, &month, &days, &hours, &mins,
         &year) != 5)
  (void) fprintf(stderr, &quot;%s: Bad date format \&quot;%s\&quot;\n&quot;, progname,


I have stumbled to this topic accidentally, as I had the same problem: after a long, arduous, but finally successful fight, I could install AMIX 2.1 to my Amiga 2000, and it worked, but it reset the date on every reboot.

I investigated the problem, and I found some interesting facts:

- The setclk command is able to handle the “three-digit” year format (e.g. 107 for 2007), but not the normal four-digit year format. It seems to be an internal limitation of the RTC device driver in the kernel (or the RTC chip itself).

- The date command is able to handle the four-digit year format, but not the three-digit format.

- The two commands call each other in a tricky way: setclk without arguments call date with an argument decoded from reading the RTC, and date with a single date argument calls setclk with the -s argument.

Therefore I tried to modify the argument passed to the date command in setclk.c to the four-digit year format.

My patch is the following (against Piru's version published here). With this patch, the compiled setclk binary seems to work correctly with both pre-Y2K and post-Y2K dates.
*** setclk.c.piru    Feb 11 10:41:14 2006
--- setclk.c      Thu Sep 27 02:56:26 2007
*** 81,87 ****
--- 81,87 ----
      if (argc == 1)
        time_t thetime = read_from_clock_device();
-       char buffer[BUFSIZ*2], tmpbuf[sizeof("MMDDhhmmYYY")];
+       char buffer[BUFSIZ*2], tmpbuf[sizeof("MMDDhhmmYYYY")];
        ** Set the system time to what the hardware thinks is correct.
*** 96,101 ****
--- 96,109 ----
        convert_time(thetime, tmpbuf);
+       if (tmpbuf[8] == '1')
+       {
+           tmpbuf[12] = tmpbuf[11];
+           tmpbuf[11] = tmpbuf[10];
+           tmpbuf[10] = tmpbuf[9];
+           tmpbuf[9] = '0';
+           tmpbuf[8] = '2';
+       }
        sprintf(buffer, "%s /usr/bin/date %s", bexleyTZ, tmpbuf);

2007 DST changes

There's been a lot of buzz about the 2007 DST changes and what they mean for IT. Well, fear not, because it is relatively simple to prepare your AMIX installation for March 11.

As with everything AMIX these days: The included utilites are obsolete, and the new tzdata does not work with it. The whole naming structure has changed. The new tzcode will not compile. Happily, if you pick and choose the data you need (I only care about the US on my system) it is easy to update the source files that come installed with AMIX for the DST changes.

Go here:
cd /pub
get tzdata2007b.tar.gz

Next, open up two shell sessions on the box. At the command prompt:

mkdir tzdata && cd tzdata
gzip -dc ../tzdata2007b.tar.gz | tar -xf -
vi northamerica

In the other window, head over to the TZ data, located in /usr/lib/locale/TZ. Back up the directory if you want to be safe. Open up the appropriate file, for example in the US it is northamerica. This is a source file for timezone data. Find the section that looks like this:

Rule US 1969 max - Oct lastSun 2:00 0 S

And delete every Rule US line in there. If you're using vi just type d6d. Replace it with the longer Rule US section (near the top after many lines of comments) from the tzdata/northamerica file you have open in the other window. If you're using X you can middle-click to paste selections. Remove the u from 23:00u on this line:

Rule US 1945 only - Aug 14 23:00u 1:00 P # Peace

AMIX doesn't like it. Next, in the /usr/lib/locale/TZ directory, if you want to go ahead and overwrite your timezone files with the new data issue the following command:

zic -d . northamerica 

You're all set. If you want to put the output files elsewhere, create a directory and change the . argument to that directory. Happy SysVR4 in 2007 and beyond!

y2k-dst.txt · Last modified: 2022/03/19 17:32 by wiki_admin