Zefram schreef: > So *legally speaking* the standard time in the UK is based on what we > now call UT1. It is an astronomical timescale.
I've read some of the relevant parliamentary debates now, and you're right. That still doesn't mean that our TZ Europe/London should be based on UT1: the time that is used all over Britain is based on UTC, as evidenced by the leap second, which is observed on atomic clocks, in the radio time signals, on the railway clocks, etc. > However, times of day stated in > Acts of Parliament remain in GMT. OK, so a "legal Europe/London" timezone is meaningful (though not really useful). As long as you're not proposing to change the Europe/London timezone itself. > It has not, but interestingly NPL promotes the loose usage of "GMT" > meaning UTC. There is one horologist(?) in the British parliament (probably the House of Lords), Lord Tanlaw, who keeps referring to the difference between GMT and UTC, and one of his suggestions is to legally change the definition of GMT to mean UTC. > >I don't think there is any country that does not implement leap seconds, > >and therefore we do not need to implement time zones based on UT1. > > I believe you're wrong there. Practical use of UTC is indeed very > widespread, but there are several countries other than the UK that still > officially define their time without reference to UTC. Countries are > very varied in how they define their time scales. Officially, perhaps. Although Lord Tanlaw refers to the UK as the only industrialized country that has its legal time based on GMT. But there are probably a lot of former colonies that have not changed their time laws. In practice, I doubt it. > >and therefore we do not need to implement time zones based on UT1. There > >may be countries that still use a time scale based on LT or LMT for some > >purposes (Saudi Arabia, perhaps; maybe even Israel?), but these cannot > >really be described as "time zones". > > If the country's legal time is defined as LMT at the observatory in the > capital city, then I'd say that country has a time zone that is based > on UT1. The whole country can be on the same time without using UTC. > > Saudi Arabia's unique feature is that it uses *apparent* solar time. > I don't know whether they reckon apparent solar time at each location > independently or use Riyadh apparent solar time countrywide. If the > latter, then again I'd say that's a time zone. Yeah, OK. But I cannot really imagine this to be the case. Unfortunately, details on the old Saudi time is not really available. E.g. in this time scale, days are not of equal length. Does that mean that there were leap seconds (or fractional leap seconds) inserted/removed every day or every few days? Were the seconds of varying length? We don't have enough information to implement this time with enough accuracy so that the difference between UTC and UT1 is important anyway. > Of course, even before countrywide standardisation of time, each town > effectively had a standard time, which could be regarded as a time zone > with small geographical extent. Ultimately I'd like to see historical > data to this effect in the Olson database, or something similar, > for processing Victorian timestamps. Not an urgent requirement, of > course, but this kind of historical work ought to at least be possible > in principle. Probably impossible, as the time (if we go back more than say 250 years) was defined for each church separately, and there are no records. And even in Victorian times, there are probably no records where each church tower got its time from. It's best to just define a LMT-module where you can plug in the geographical location. (See below) > Riyadh time could be > given as "[EMAIL PROTECTED]" or something. Maybe that's the interpretation > you intended for "LMT+46d43m27s" after all? Yes. Apologies for the LAT/LMT confusion; I first used the example of Paris Mean Time there. But I meant it as signifying the location of the LMT/LAT. > My general opinion is against using explicit angle measures, though. > We definitely want to be able to give offsets in time units, and the angle > units would be a redundant mechanism. In this context we essentially > state angles using time units, and I don't think there's a problem with > sticking to just the one set of units. Hmmm. Just like the Olson time zones are not named UTC+1/2 (for example), I'd like the LMT/LAT time scales to have a more meaningful notation than just the time difference with GMT/GAT. [EMAIL PROTECTED] is IMHO a better notation; generalizing that, I would include the longitude of the location. (Too bad that longitude is measured in degrees; not in hours, like right ascension in celestial coordinates.) But time difference should be implemented anyway, so if only one set of units is to be used, that would be the one. > >As I said above, there is no practical value in such a timezone; it is > >certainly not what is used in Britain. No need to invent a convenient > >notation for it. > > As discussed I think there is value in such a timezone. Whether a > notation for it is required is an open question in my mind. I'd much > rather have the ability for named timezones to have a non-UTC basis > built in. Either way, it's a feature that we don't need immediately. OK, we can agree on that. There is value, but it's not an immediate need. But you asked what notation to use, right? We have simple cases: +01:00 - offset; interpreted as timezone relative to UTC (always) Europe/London - Olson time zon; possibly using DST; relative to UTC UTC - time scale; no offset or DST rules UT1 - ditto (and also: GPST, TAI, "GAT", ...) TT/TAI - time scale, with specific realisation Combining these... UTC+01:00, UT1+01:00 - offset+time scale UTC-Europe/London, UT1-Europe/London ??? - Doesn't look too bad? and even: TT/TAI-Europe/London - I have no idea why this would ever be useful... > What you should aspire to with DateTime is first to do all those > calculations, with a suitably abstracted interface. Don't compromise > on the abstraction or functionality of DateTime to get its performance > up to what purchron achieves. Sure. For performance in DateTime, I would optimize for the common case (UTC, with possibly an offset/Olson TZ) anyway, whilst keeping the other time scales in mind when in implementing the interface. > For my own libraries, I'm finding that I'm implementing several things in > real-time and non-real-time versions. purchron is where all the real-time > stuff goes, though I might make another library out of that some day. It's a nice program anyway. User interface could be better, but I like the output. I have it now running with local time, UTC, GPST, TAI and TT. When do you plan to implement UT1 (using the published values, some interpolation and extrapolation, and some (no doubt inaccurate) equation for the deceleration of the earth's rotation? ;-) Eugene
