Eugene van der Pijll wrote: >> Civil time in the UK is not legally based on UTC; > >I believe this to be incorrect. British Standard Time, aka >"Europe/London", certainly observes leap seeconds, and is therefore >based on UTC. Maybe the legal definition is still in terms of GMT,
(The name "British Standard Time" is not appropriate here; it refers to a brief period when UK time was defined as GMT+1 all year round.) The fuller story: UK time is currently legally defined by the Interpretation Act 1978 <http://www.swarb.co.uk/acts/ 1978InterpretationAct.shtml>. The clause in question reads: # 9. Subject to section 3 of the Summer Time Act 1972 (construction # of references to points of time during the period of summer time), # whenever an expression of time occurs in an Act, the time referred # to shall, unless it is otherwise specifically stated, be held to be # Greenwich mean time. The Summer Time Act 1972 is what determines the UK's current offset from GMT. Lots of later legislation governs when the offset changes occur in particular years; now this is governed by EU-wide law. Greenwich Mean Time had, and retains, a strict meaning of local mean solar time at the longitude of the transit instrument at the Royal Observatory, Greenwich. That is very much the meaning in effect in the 1978 Act. Similar wording occurred in the 1880 Act which first standardised on the use of GMT in Britain. In 1997 the Coordinated Universal Time Bill was introduced in Parliament. If enacted, this would have replaced legal use of GMT with UTC (or, in a proposed amendment, UTC(NPL)). The Bill ran out of Parliamentary time and was never enacted, and it has not been reintroduced. There's a web page about it at <http://wwp.greenwichmeantime.com/ time-zone/europe/uk/time/british-summer-time/parliament/ co-ordinated-universal-time-bill-1997/>. So *legally speaking* the standard time in the UK is based on what we now call UT1. It is an astronomical timescale. As a practical matter, however, time signals disseminate UTC, not UT1. UT1-based time signals, which were universal until the 1950s, are rather impractical: they're impossible to keep synchronised, and they make poor frequency standards. That's why UTC was invented. The main supplier of time signals in the UK, the National Physical Laboratory, which is incidentally where the first caesium atomic clock was developed, was one of the early adopters of atomic-based time signals in the late 1950s. They've been signalling UTC, rather than UT1, as long as UTC has existed. Because the difference between these two scales, |UT1-UTC|, is kept below 0.9 s, for most practical purposes UTC is an acceptable approximation to UT1. It has therefore not been a problem that the time that NPL disseminates is not quite UK legal time. Now that sub-second synchronisation of clocks is widespread, the usual civil practice in the UK is to synchronise to UTC, and to observe leap seconds. The law, of course, doesn't actually prohibit the use of UTC for any purpose. Contracts can specify deadlines in UTC, as long as they say that that's what they're doing. I expect that this is exactly what does happen in the stock markets, where trade times are attaining the kind of precision where that matters. However, times of day stated in Acts of Parliament remain in GMT. If the sub-second difference were to attain legal significance in, say, a pub licensing case, then the UT1 interpretation of legal deadlines would prevail over UTC. > So either practice deviates from >law, Common practice deviates from the legal default. > or the legal term GMT has been implicitly redefined to mean "UTC". It has not, but interestingly NPL promotes the loose usage of "GMT" meaning UTC. Perhaps we need to distinguish between common-civil-practice time and legal time. There's a great precedent for this: after the railways invented standard time, common practice gradually changed over to using railway time. But the legal default remained local solar time for some decades. Elections and court opening hours were among the last things to switch to using GMT. >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. You should think of UTC as a mechanism for time dissemination here. It's the infrastructure that everyone uses, but the official interface is not UTC everywhere. >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. 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. >Agreed. May I add "POSIX" to that, a time scale in which some seconds >last twice as long as others? Interesting idea. I hadn't thought of treating it like that. That could work very well. Here's another case where law and common practice diverge, though. POSIX says that the time_t value repeats the second after midnight. The ntp_gettime() interface says that the second *before* midnight is repeated, and BSD actually implements that. Linux doesn't do either: it does roughly NTP semantics, but the time_t warp isn't synchronous with the second boundary, so it actually repeats something like 23:59:59.005 to 00:00:00.005. Time::UTC::Now has decoding logic to handle any of these variations. >If I were to implement these time scales for DateTime, I would probably >implement them as subclasses of UT1 (or "LMT") and LAT, with the >geographical longitude as parameter; "LMT+46d43m27s" for Riyadh legal >time, for example. But your notation is reasonable as well. I don't like the notation "LMT+" anything. "LMT" means "local mean time", but we're not offsetting from local mean time, we're offsetting from Greenwich mean time to *get* local mean time. So "GMT+03:06:52" is a type of LMT, specifically the LMT of Riyadh. And in the Riyadh case it's *apparent* solar time that we want, not mean time which you've slipped into there. Using the longitude instead of time offset: that's possible, not entirely unreasonable, but in your syntax it'd be confusing. "d", "m", and "s" in a time context are liable to be interpreted as "days", "minutes", and "seconds". I think actually we don't want to give offsets in angles: "GMT plus fifteen degrees" has never been an accepted usage. But we could specify "local mean time of fifteen degrees east". Riyadh time could be given as "[EMAIL PROTECTED]" or something. Maybe that's the interpretation you intended for "LMT+46d43m27s" after all? 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. >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. >I don't really like it. The difference between GPS and TAI can easily be >given, because it is fixed (more or less, I suppose; it's the difference >between GPS and TAI(GPS) that is fixed, right?). But you cannot define >time scales in general using this notation. As an example: what was the >difference between TAI and UTC during the last leap second? UTC certainly can't be defined that way. But then, Europe/London (whichever basis it uses) can't be defined as base plus fixed offset, or even using the insanely complex POSIX syntax to specify dates of offset switches. The intent was to allow a mechanism that handles a common set of cases without requiring a new timezone to be named and added to the database. On reflection I think there aren't so many time scales that could use this as to make it really worthwhile. For the moment, having to name all our base time scales doesn't seem too onerous. And I hope that time scales that are just fixed offsets from other time scales will not proliferate. >I like it. I would like to reach a point where we can implement this in >DateTime. There are some considerations for that which you probably don't want to influence DateTime. In a real-time clock program, overhead is important. You'll notice that purchron does some bignum stuff with the libraries, but that's all relegated to the non-RT thread which researches stuff in advance. All the calculations in the main thread are done in open-coded native integer arithmetic, to get the new display frame out as quickly as possible. I'm quite pleased that I get acceptable performance from pure Perl, without having to resort to C. 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. 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. -zefram
