On Sat, 2008-09-06 at 13:22 -0700, Alan W. Irwin wrote:
> I suggest we specify our continuous time variable as a TT Julian day
Personally I think this is nearly as good, or bad, as any other choice
because it will suit some people and confuse others. I would like to
draw a distinction between what we use internally in plplot and what we
advertise to the user interface. My most recent recommendation was that
we didn't advertise any single system to the user, so that they would be
free to work in their own. There are several examples of this, most of
which involve situations where there is a well-defined zero epoch, or
some other representation, e.g.,
* time since the beginning of an experiment or some other event
* time since 0AD (this is the NASA CDF epoch and yes, they know there is
no such date!)
* time relative to the peak in sunspot number
* time as measured by some clock, e.g., spacecraft event time (SCET)
* localtime, calendar time, and other things provided by C and system
The reason why users want to regard some of these (e.g. the first) as
time is to label the time axis in hours, mins, secs, and/or whatever
rather than a counter. With a clear statement that leap seconds are
ignored (C's calendar time apparently includes leap seconds on some
systems and not on others (!)), all continuous times (the user's, TAI,
TT, GPS) can be related by a simple offset (and multiplicative factor
from days to seconds or milliseconds) even outside their formal range of
validity. Don't pick this statement apart because it isn't necessary.
The point I wish to make is that as long as the user is clear about how
they want their continuous variable to be broken down into years, days,
hours, mins, secs, etc., internally we can represent this in a way that
is convenient for us.
It would be helpful for them if we provided some helper utility routines
to offer translation services, including TT, CDF, etc. in response to
demand. What I am trying to avoid is someone being asked to convert
their time into TT and having to dig out an algorithm to calculate
Julian day, get it wrong, worry about leap seconds (and years), etc.
This is why I suggested that we simply let the user tell us that
continuous time value 1357234.98765 corresponds to 1982-06-04
13:24:18.654 and then we do the rest internally (which for us is a
simple matter of calculating an offset to get to whatever internal time
we use. Again, this offers simplicity to the user in that for most
purposes they will not need to touch their data at all or, at worst,
divide it by 24*3600 to convert from seconds to days.
Actually, I suggest we postpone most of this discussion until we solve
the two-variable problem of handling time. See below.
> and our broken-down time variable also in TT.
I firmly believe that we need to give the user the tools to provide
times in years, months, days, hours, mins, secs and not as (or at least
in addition to) a Julian day number and fraction (or hours, mins,
secs, ...) of that day. There are just too many applications where JD is
not meaningful to the end-user. Maybe this is what you meant, but I
wanted to be clear.
> Julian days are not so good if you have just one continuous time
> variable, but with two double precision numbers representing that time
> variable, the first variable can represent the integer part (exactly
> for an extremely wide range of epochs) and the second variable the
> fraction of the day. This is exactly how the independent variable of
> the JPL ephemerides of the planets is represented, and this time
> representation gives you an absolute numerical precision of 1.d-17 of
> a day. That works out to 0.001 ns which should satisfy most needs.
Your solution is fine for storing high resolution time information.
There are other places one could make the split between the two parts
that we could argue about forever depending on the application, but
let's not for the time being. There may also be a good reason for having
an overlap between the two parts so that, for example, the leading part
holds accuracy down to milliseconds while the 2nd variable holds
fractions of the day (down to sub-nanosecs as you describe).
I'm thinking about the implementation within plplot, rather than the
intrinsic accuracy of the time. While the user's data may need to worry
about, and retain, the latter, the accuracy of a plot is limited to a
few thousand pixels or so. This opens questions at two levels:
What does the interface look like to the user (e.g., what gets passed
through plenv or plwind to define the tmin and tmax range, what gets
passed to plline or plpoin as the x-variable)?
What does the user get back from plGetCursor?
How are the world coordinate limits of the window held?
How are these handled to divde and label the time axis?
How does plplot then handle these to put the points and lines at the
How are cursor values then converted from (presumably) device
coordinates returned by the driver to world coordinates to be returned
to the user?
I don't have an answer to these, and will discuss with my team over the
coming weeks as we drift in and out of the office. But here are some
a) we'll need to be able to manipulate (add/substract) high-precision
times without losing accuracy
b) once the range of a window (tmin, tmax) are known, we should be able
to hold that as, say, the high-resolution time at the tmin plus a
relative time; given the resolution of the plot, there should be
suitable units to ensure that these relative times can be held in a
single number. This would solve (ease) things in that all the existing
plplot routines (plline, plGetCursor, ...) would then need little, if
c) this would be even better if instead of using offsets from tmin we
did it from some convenient offset, say the beginning of a day
d) if we used a two-variable time that had overlaps, e.g.
then for 99.9% of the cases the user could use a single variable and we
could get away with a single flag somewhere to switch between years and
seconds as a base). Here dddddd is a fractional day; double precision
(16 decimal places) would get us down to something like milliseconds if
I've calculated correctly. SS.SSSSS effectively repeats that ddddd...
part, but as seconds, and extends it to sub-nanosecs. If we used an
epoch closer to the present (or closer to the user's tmin), we could
gain 3 digits or so for ddddddd..., which would be a big bonus (for
those of us working precisely in this millisecond range).
This overlap approach wouldn't quite do what the user might want for
time intervals of microseconds or less that straddled midnight, but
we'll never be able to please all the people all the time, and I think
in practice this is even less likely to be a problem for some than the
leap second issue we've agreed to duck!
Actually, I just noticed (on the wikipedia pages) that Julian date
definition starts a day at NOON. It's pretty obvious why astronomers did
that (since most historical time standards, gmt, etc., are based on the
transit of the sun overhead) but others might find this confusing. It
certainly differs from the ISO notion of time strings of the form
YYYY-MM-DDTHH:MI:SS.ssssZ as well as from everyday usage.
That's all for now. One of my concerns is to make this simple for us as
well as for the user, and that means both retaining as much of the core
plplot intact as possible on the one hand, and transferring over things
we've done here with only modest tweaks on the other (e.g., my simple
patch to fix mktime, which were almost a pure cut'n'paste from our
existing code). None of us have infinite time even if we could figure
out a way to represent such a notion :-)
Professor Steven J Schwartz Phone: +44-(0)20-7594-7660
Space and Atmospheric Physics Fax: +44-(0)20-7594-7772
The Blackett Laboratory E-mail: s.schwartz@...
Imperial College London Office: Huxley 6M70
London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs