time zone survey

[Dik.Winter at cwi.nl]

 > 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.