Zefram schreef: > It also explicitly lists some that are based on GMT: the European Union,
I don't think this is actually true. The page quotes a European directive on summer time. Directives of the European Union are published in all official languages of the EU, and all of the versions are equally valid. In the English version, the transition date is given as "1.00 a.m., Greenwich Mean Time", but the French document says "1 heure du matin, temps universel", and the Danish translation is "kl. 1.00 om morgenen, verdenstid (UTC)". The actual situation in the EU can be more accurately described as "confused". > Ireland, Namibia, United Kingdom, United States (former colony!), and > the canadian provinces Ontario, Saskatchewan, and Quebec. So the noble > Lord was in error on that point. Well, he said _industralised_ nations. If the most important exceptions are Ireland, Namibia and Saskatchewan... > Unix timestamps > that predate precise UTC synchronisation are ambiguous in just this way, > and so Unix time in that era is best understood as being based on "UT", > rather than UTC or GMT specifically. This seems to be the best way to > think about DateTime's current time scale too, when working outside the > range of known leap seconds. I agree about that. > With that interpretation of the Olson database, an implementation is > free to use the database's offsets with whatever form of UT it finds > most convenient: most likely UTC. Until the database does properly > address the issue, let's not perceive information that's not there. So then we're back at the situation I described in the previous mail: "Europe/London" describes a system of offsets and DST rules, but not a base time scale; "UTC+Europe/London" and "UT1+Europe/London" are two time zones, based on two different time scales; if the time scale is not given, a default has to be assumed, and the easiest, most practical, and not obviously invalid assumption is UTC. Something like that anyway. Eugene
