Hi Alan, 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 > number
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 clocks 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: User interface ============== 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? Internal interfaces =================== 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 right place? 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 thoughts: 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 any modification. 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. (JD.dddddd..., SS.SSSSsssssssss) 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 :-) Regards, Steve -- +-------------------------------------------------------------------+ 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: [EMAIL PROTECTED] Imperial College London Office: Huxley 6M70 London SW7 2AZ, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs +-------------------------------------------------------------------+ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
