Eugene van der Pijll wrote:
>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.
I'd initially imagined actually changing Europe/London, but on reflection
I realised that would be awfully disruptive. I think it'd be best to
have Europe/London/Legal, with Europe/London being the common-usage form.
Historically there's some point before which common usage is based on
UT1 rather than UTC. Something I missed out from my earlier analysis:
the choice of base time scale, as well as the offset from it, can vary
over time within a timezone.
Interestingly, in the prehistory before UTC but after the invention of
the caesium clock, several time signals operated an informally-specified
system resembling the rubber-seconds UTC: a frequency offset changing
infrequently, with jumps of 20 ms to stay close to UT1 or UT2.
They weren't internationally synchronised until 1960, leading to UTC
in 1961. We could model these as yet more time scales using the same
mechanism as for rubber-seconds UTC.
>There is one horologist(?) in the British parliament (probably the House
>of Lords), Lord Tanlaw,
It is he who introduced the Coordinated Universal Time Bill.
>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?
In apparent or mean solar time, every day contains exactly 86400 seconds
by definition. The second here is really a unit of angle, not of time
as we now understand it. The duration of such a second is continuously
variable. There are no leaps.
>even in Victorian times, there are probably no records where each church
>tower got its time from.
There are plenty of records along the lines of "Cambridge time is 3
minutes ahead of London time". These differences were well known and
quite stable. It was, in fact, a timezone system, in that era.
>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.
My intention was that you'd be able to name a GAT+offset zone if useful.
The offset syntax is for occasions when an unnamed zone is temporarily
required.
>+01:00 - offset; interpreted as timezone relative to UTC (always)
I'd like to deprecate the bare offset. I think the base should be
explicitly specified.
>Europe/London - Olson time zon; possibly using DST; relative to UTC
I want to be able to name zones that are not based on UTC. Certainly want
to have timezone data that predates the existence of UTC. The choice
of base timescale is a feature of the zone, not fundamental to the
timezone system.
>UTC - time scale; no offset or DST rules
>UT1 - ditto (and also: GPST, TAI, "GAT", ...)
>TT/TAI - time scale, with specific realisation
We have two distinct uses of "/" here. Need to think about how to
disambiguate. If a syntax were to be defined from scratch then I'd
rather use "." for multi-part names and "/" strictly for realisations.
"Europe.London" looks good to me.
>UTC+01:00, UT1+01:00 - offset+time scale
Yes.
>UTC-Europe/London, UT1-Europe/London ??? - Doesn't look too bad?
If this feature is to be supported, I'd prefer to make it explicit that
you're taking the offset part of the named zone and ignoring its built-in
base time scale. Also better to use "+" than "-" here, lest it appear
that you want to apply the opposite of the UK time offsets.
>TT/TAI-Europe/London - I have no idea why this would ever be useful...
There's a serious possibility, on a decadal timescale, of legal and
civil time in some jurisdictions switching away from a UTC basis to be
based on TAI. Using TT(TAI) is less likely, but a reasonable variation.
I think allowing TT(TAI) in than syntactic position is just as reasonable
as allowing UT1 and GAT.
I've looked at the kinds of names used in the Olson database. There are
555 names in total in the current version. They fall into several
identifiable classes:
* pure geographical, matching qr#(?!Etc/)[A-Za-z]+(/[-_A-Za-z]+)+#
* hack poorly implementing Riyadh apparent solar time, matching
qr#(Asia|Mideast)/Riyadh\d\d#
* System V style $TZ values for US zones, matching qr#[A-Z]{3}\d[A-Z]{3}#
* fixed offsets from UT, matching qr#Etc/GMT[-+]\d\d?#
* names for UT, matching qr#Etc/[A-Za-z0]+#
* short names for UT, matching qr#GMT[-+]?0|[A-Za-z]+#
* deprecated shord geographical names, matching qr#[-A-Za-z]+#
* placeholder zone for use as system default, matching qr#Factory#
Of these eight distinct classes, I think we only want the database for
the first class of name (pure geographical). If we're extending the
timezone namespace then we can decide for ourselves what to do for
backward compatibility. Conveniently, the pure geographical names
follow a fairly restrictive syntax: no digits, no "+", no "-" in the
first component.
>User interface could be better,
Which aspect of it? User friendliness was certainly not a major
consideration in writing it, but I'm open to suggestions.
> 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? ;-)
I certainly do plan to do the astronomical time scales. I'm gradually
researching sources of TT<=>UT1 data. The IERS publishes measured daily
values of UT1-UTC, and each week publishes daily extrapolated values
for the next year. That gives me recent history and near-term future.
For long-term future we have good models of the secular deceleration:
it's pretty linear. Phase lock is lost, but interval calculations
will work. Medium-term future I'm concerned about, because IERS has
the knowledge to extrapolate years out but doesn't publish either the
models or the predictions AFAICT. For the past, going back a couple of
centuries, actual measurements exist, but I don't know where to find them.
For earlier recorded history there are some very isolated measurements
from eclipse records, also requiring research. In prehistory we've got
archaeological and geological evidence of LOD, but of course no phase
synchronisation.
I'd like to put all this knowledge behind a consistent interface.
So tt_to_ut1() and ut1_to_tt() functions will hide the complexity of
multiple data sources. Also want tai_to_ut1() and ut1_to_tai(), for
greater precision in the TAI era. (UT1-TT(TAI) is known somewhat better
than UT1-TT, because of the uncertainty in TT(TAI)-TAI.)
I really want to have explicit uncertainty bounds as part of this
interface. I ought to add them to the Time::TT conversions too: they're
conspicuously missing, but unfortunately the uncertainty data is also
conspicuously missing from the data files that it downloads from BIPM.
The real-time version of UT1 in purchron only needs to look at IERS
forecasts. Ideally I'd like to do that by using the non-real-time
tai_to_ut1() in the background and then doing piecewise linear
interpolation in the display generator. But since handling the IERS
forecasts alone is much simpler than the full UT1 module, I might do
the IERS bit on its own in purchron first.
-zefram
