Attached are results from a casual time zone survey. An interesting survey.

I tossed out data with unzoned time stamps, data without a recognizable domained system name in the Message-ID, and data from ".com" sites. Why did you toss out data from ".com" sites?

1 +0530 1 Jun 93 15:30:55 +0530 imtech.ernet.in

This might be a valid one. It is apparently from India which lives around +5 and +6.

1 +0611 Wed, 02 Jun 93 16:08:33 +0611 trashcan.hacktic.nl

This one is definitely invalid. Most probably a PC hooked up to hacktic (a public access system in the Netherlands). Probably the owner did set it up wrong.

1 +0730 6 Jun 1993 08:25:56 +0730 news.Colorado.EDU

Ha! If even Colorado.Edu cannot get it correct! ;-).

MESZ Middle European Standard Zone Probably "Mittel Europ"aische Standard Zeit".

MEZ Middle European Zone (used primarily in Germany) "Mittel Europ"aische Zeit". And yes, primarily german speaking countries.

BSC ? Tue, 25 May 1993 10:51:05 BSC FINHUTC.HUT.FI Tue, 1 Jun 1993 11:57:00 BSC brfapesp.bitnet These two are definitely not in the same timezone. One is in Finland, one in Brazil.

TUR Turkey? Probably yes. All sites are in Turkey.

The results make me think there's little prospect of discovering useful time zone information (in particular, time transitions that don't already show up in tzdata93c.tar.Z) from running through news articles; someone with an account on a site that does extensive archiving of news might prove me wrong. I think there is no prospect at all. And it will grow worse. In the case of the "hacktic.nl" machine we see that we have a single machine that is configured wrong. I think more of this kind of machines will emerge. They do not care what time the system runs on, as long as it is internally consistent (and even that is not needed at all times). Time transitions especially will be a problem, and it will continue to be a problem. At our institute during the transition to DST all Suns (which use your package) switched on time, but all SGI's (using SysV's method) did not. The system administrator simply had forgotten to update the file that contained timezone information (/etc/TIMEZONE) and it took a few days before somebody noticed. (Yes, in SysV the file has to be changed every year again. And SGI shows no inclination to change.) So I think nobody will prove you wrong.