Order of the Bath

I am posting this entry at exactly 10:00 BST = 09:00 UTC, from the Office, where I know the clocks are accurate and reliable (I wrote the piece much earlier). As you will observe from the time of posting above (or below), the Web Host server clocks are far from accurate. Not as far out as I posted on Monday because I misread the time zone charts — PDT is only seven hours behind BST not eight as I thought — but still pretty bad.

Why should this matter? Well, for a start, it looks very silly if the clock on your screen is not right, and you miss appointments. It is also inconvenient. For example you get emails arriving before they are sent and the FTP “upload if newer” features don’t work properly.

But, there are much more important reasons. If you are trying to diagnose a problem then you have to be able to rely on the time stamps in system logs, particularly for network related issues where more than one machine is involved. I am trying to work with the service provider to solve a problem with some emails not getting through. I can send some test mails through at a particular time and they need to look at their logs to see what happened to them. If the time stamps are not right they do not stand a chance of locating my test mail among the many thousand passing through their server. If they ever have to use their logs in a legal case, e.g. prosecuting a cracker, then it will be (should be) thrown out of court if they can’t demonstrate that the clocks were accurate. Perhaps (sly grin) this is why they keep it wrong, so they can’t be forced to produce email evidence for criminal cases?

There is really no excuse for incorrect clocks; there is a perfectly good and free to use system called NTP which can synchronise to any number of publicly available reference systems and, for an internal network, it is straight forward to set up a cascade so that even the humble desktop can be kept within a few milliseconds of mythical “True Time.” For Windows systems, if you should be so afflicted, there are compatible systems available.

Whilst investigating this I came across a related problem which I thought had died out years ago. When setting up WordPress for this blog it asked for my offset to UTC (Coordinated Universal Time en Français) so that the posts would be stamped with my local time (UK). Except that the time it reported as UTC … wasn’t. It was an hour out due to Summer Time (called Daylight Saving Time in some parts of the world). Now I don’t know if WordPress was reporting it wrong, or PHP was returning it incorrectly (unlikely) or the server has been set up badly, but it certainly was not right. When you set the clock on a machine it has to be set to UTC and then any necessary time zone and DST offsets applied. Many systems rely on this being right; for example, EMail time stamps have the UTC (GMT) offset included in them so that at the receiving end they can be converted back to UTC and then to the new local time so it makes sense to the recipient. NTP sorts all this out automatically because it has to work in UTC internally, but if you are relying on the operator;s wrist watch then he is going to set the clock to what he sees and if the time zone has been left at the Zulu factory setting then everything is going to be haywire.

Late Note: I have tested WordPress date reporting and it is OK; PHP function date("H:i T I") returns 10:00 GMT 0 (i.e. no DST) so it is the server that is set up wrongly!

This entry was posted on 5 Oct 2005 at 10:12 by Rick and is filed under Technical. You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.