Zefram schreef:
> I note that DT::TZ::TAI
> attempts to treat TAI as a timezone, which doesn't work 100% but does
> put TAI in roughly the right relationship to the other DT objects.
As you say, TZ::TAI does not work 100% prefectly. It has turned
out to be impossible to implement it correctly, because of how timezones
are currently implemented in DateTime. I have some ideas to decouple
time handling from date handling in DT, to make it easier to implement
additional time scales. I'll get back to this someday, I hope.
> Civil time in the UK is not legally based on UTC;
> legislation to make it so was defeated some years ago. London civil time
> is legally still based on GMT, or more precisely UT1.
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, but
this is certainly not used in Britain. So either practice deviates from
law, or the legal term GMT has been implicitly redefined 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. 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".
> There is currently an
> implementation limitation that we only get UTC as the base time scale
> >from these names. I think we should plan for this limitation to be
> lifted in the future.
As I said above, I don't think this is necessary for any current time
zone.
> How to represent base time scales? I'll start with some that I think
> should definitely work. "TAI" should refer to TAI, and "GPST" should
> refer to GPS time. (I want `TZ=TAI date` to work in some future version
> of Unix.) These go alongside "UTC" already meaning UTC. Note that
> such single-component names (except "UTC") are deprecated in the Olson
> database, *when used to name timezones*. Such short names are definitely
> the right way to be specifying widely-used time scales.
Agreed. May I add "POSIX" to that, a time scale in which some seconds
last twice as long as others? It's not respected very much in
time-keeping circles, but implementation of this "time scale" may be the
best way to map UTC to "Unix system epochs".
> How is TT(TAI) to be specified? The parens seem awkward. In another
> context I used "TT/TAI" for this, because it can go to multiple levels.
> TT(TAI(GPS)) ("TT/TAI/GPS" in my slash-based syntax) is Terrestrial Time
> as calculated from TAI as supplied by GPS. Slashes don't seem like a
> good idea here because of clash with the hierarchical geographical names.
I do like slashes, because TT is more or less hierarchical as well:
TT/TAI and TT/BIPM04 (and others) are members of the same "family" of
timescales.
> I'd also like to be able to specify an offset along with the time scale.
> The offset is to be treated as a timezone, not as part of the base scale.
> Giving a numerical offset is useful to specify local solar time. So,
> for example, I can specify Paris Mean Time as "UT1+00:09:21" or something
> like that. Hypothetically, if we had "GAT" for Greenwich apparent solar
> time, we could give Riyadh legal time as "GAT+03:06:52". There's a
> slight awkwardness that "-" and "+" are valid characters in geographic
> timezone names, so it might be necessary to modify this syntax a bit.
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.
> To specify these offsets, I think the formats "+hh", "+hh:mm",
> "+hh:mm:ss", "+hh:mm:ss.s" should definitely be possible. It might also
> be useful to allow the variable-length ISO 8601 period duration format, so
> "+3m" (for +00:03) and "+76.3s" (for +00:01:16.3) would also be allowed.
> There doesn't seem to be any parsing trouble in store there.
Seems OK.
> Getting more obscure: as a workaround for the limitation of the Olson
> database, it might be useful to specify a base timezone and add onto
> that the offset rules from a geographical civil timezone. Legal London
> civil time is essentially UT1 + offset_rule_of(Europe/London). Should we
> have a syntax for that?
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.
> Similarly, what about generating a new base time
> scale by offsetting an existing one? GPS time is TAI - 19s, so perhaps
> similar cases should be specifiable in this manner. But the syntax
> must be conspicuously different from that used to add a timezone offset,
> because this offset is part of the base time scale, not a timezone.
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? TAI was
2006-01-01T00:00:32.5 halfway during that second. UTC = TAI - 32 seconds would
imply that UTC was 2006-01-01T00:00:00.5; UTC = TAI - 33 seconds would
imply a UTC of 2005-12-31T23:59:59.5. Neither of them is correct. (This,
by the way, is the reason that DT::TZ::TAI does not work as a time
zone.)
So a short notation defining one time scale in terms of another would
only work in very simple cases, where the two time scales are actually
two representations of the same scale. I don't think you should
introduce such a notation, as the benefit would be low, and the
temptation to use it in cases where you can't would be too high.
> My experimental code is at
>
> http://www.fysh.org/~zefram/time/purchron
>
> For a multi-scale display, do
>
> $ purchron
> '____(fixed,UTC:)_(ymdhms,UTC,9,-1)/___(fixed,GPST:)_(ymdhms,GPST,9,-1)/____(fixed,TAI:)_(ymdhms,TAI,9,-1)/(fixed,TT%28TAI%29:)_(ymdhms,TT_TAI,9,-1)'
I like it. I would like to reach a point where we can implement this in
DateTime.
Eugene
