I'm developing some code that provides a real-time clock display,
in conventional hours-minutes-seconds format, and handles multiple
time scales as well as ordinary UTC-based timezones. As a result,
I need a way for users to textually specify which time scale to use.
I'd like this syntax to be discussed and agreed by this list, partly to
avoid gratuitous incompatibility in the future. (I expect that DateTime
will handle multiple time scales at some point.)
My thoughts on this so far...
Time scales should be specified in the same slot in which timezones
are already specified, such as the $TZ environment variable. "TAI"
and "London civil time" are both reasonable answers to "which time
scale?" questions that these slots answer. 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.
Time scales are *not* timezones, not precisely. They're more akin to
different flavours of Universal Time. We can specify the TAI time as an
MJD, and the UTC time as an MJD, and the UT1 time as an MJD, and these are
all different MJDs. But "London civil time" can't be expressed as an MJD.
Applying a timezone offset doesn't change the MJD; what it changes is
what gets displayed relative to the MJD. What gets displayed can be
represented in isolation by a CJD, so applying a timezone offset does
change the CJD. The timezone offset determines the MJD<->CJD mapping.
What I'm trying to fit in where timezones have formerly gone is really
composed of two things: firstly a base time scale, and secondly a set of
offset rules that determine what gets added to the base time for display.
When, in ISO 8601 form, we display "17:53:12+01:00" this says that the
base time is 16:53:12 and the offset is 1 hour; it does *not* say which
time scale the base time is in or how it relates to any other. This is
another view of how the offset that comes from a timezone fundamentally
differs in kind from offsets between base time scales.
The geographical timezone names such as "Europe/London" are trying
to identify, e.g., "London civil time". The Olson database currently
provides only timezone offsets under these names, and in implementation it
is assumed that the base time scale is UTC in every case. That model is
not strictly correct. 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. Countries vary
between whether they use UTC or UT1 as their base time scale, and I
think some might still be using *apparent* solar time (which can differ
by many minutes from UT1). Saudi Arabia was definitely still using
apparent time in the late 1980s, and the Olson database goes through
some amusing gyrations to attempt to support it.
So: ideally a geographical timezone name should actually identify both
a base time scale and a set of offset rules. 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.
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.
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'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.
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.
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? 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.
Finally, there are situations where only a base time scale is to be
specified, and timezones are not permitted. Displaying an MJD is such
a situation.
Congratulations if you've made it this far through this message.
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)'
-zefram
