Friday, 13 February 2015


rdate is very nice. It keeps my computers on time.

Computers have a clock, but it isn't accurate. Far from it. People often wonder why computer clocks are so inaccurate - the answer is, they aren't clocks, they're computers. It would cost nearly $0.01 to make computers have accurate clocks, so it isn't going to happen.

But when you have a network, it's good to have all your computers have the same time. This is because some things need to happen after other things, and if they're on different computers, you need the clocks to be together.

Enter rdate. Once per day, I run "rdate -s" on my computer named xanth, and once per day, I run "rdate -s xanth" no all the other computers. rdate gets the time from port 37, on a service called "time-stream", which is built in to xinetd, the super-server, which I install by default on all my servers.

This works well. But it might not work in future. rdate has become "deprecated", and is on the way to being obsolete. That's a shame, because it means that one day I might have to change everything.

There's ntpdate that replaces it, which is a client to ntp (network time protocol). That's altogether more sophisticated and much more clever, and can syncronise much better than the "within a second or so" that rdate does. But the rdate sync is good enough for me. I hope I can continue to use it in future, because changing everything over to use ntp will be a bit of a pain.


  1. How about on 30 June 2015 when a “leap second” will be added to the day? There is a risk that a small number of systems may fail when this extra second occurs.

  2. I remember the "millenium bug" thing. There was a big pre-millelial panic, lots of people checked their systems, and then, according to the folk wisdom, nothing happened.

    Except it did.

    My systems for billing credit cards stored the card expiry date as mm/dd/yy, only two years for the date. And before I billed a card, I'd check that it was still within the expiry deate, by doing a simple subtraction. If I hadn't done anything about it, then when the year became 00 instead of 99, my systems would have refused to bill any cards. Of course, I knew that would happen, so I changed my software to deal with it.

    But I also know that the banks had a problem, because between January and March of 2000, no cards were being issued, and that cuold only mean that they were having a problem, I don't know what.

    The leap second isn't going to bother me. I don't have anything that's synchronised to the second, if a clock is a few minutes out, that won't cause me a problem. It's only when the drift goes over an hour that I'd get a problem.

    Oh, and you're probably wondering why I used mm/dd/yy instead of the more normal dd/mm/yy. It's because I wasn't thinking clearly enough when I designed the system, and I decided to use US-style dates. For no good reason. And I haven't changed it since then, because it's not worth the effort (and possible introduction of a bug) to change to the UK style of dd/mm/yy, although for everything *except* billing, that's what I use.