Hi Steve: I agree with almost everything you have said. For example, I very much agree with your general idea of keeping everything as simple as possible.
The one area where I think we need more discussion is the time scales we use for our continuous and broken-down times. On 2008-09-06 15:26+0100 Steve Schwartz wrote: > [...] all we really need > to do is provide a visible mapping from a continuous variable to > (YYYY-MM-DD:HH:MM;SS.SSS...) and this can be presented to the user > without specifying where the zero for the continuous variable is. Thus > we could accommodate time in any system; that would save the user the > trouble of re-calculating timetags, and they could label the time axis > with the appropriate label (UT, TAI, Time since birth of my 2nd child, > or whatever). I am going to change my ground yet again. Sorry about that, but your points about GPS time were well taken, and also I keep getting new ideas and reminded of old ones as I extend my website reading about time representation. However, I doubt I will be changing my ground again because I really feel comfortable with the following proposal. I hope you like it as well. I suggest we specify our continuous time variable as a TT Julian day number and our broken-down time variable also in TT. My latest proposal is based on what you can read at http://en.wikipedia.org/wiki/Terrestrial_Time. That web page has reminded me of the importance of both TT and Julian dates. The reason I want our continuous time variable expressed in Julian days is that is an extremely popular time variable for astronomy and certainly much more useful to our users than any other continuous time variable I can think of. For example, in earlier discussions of time on the PLplot list, one of our (non-astronomical) developers already has expressed an interest in Julian dates, and as an astronomer I have to agree with him. 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. The reason I like TT is it is defined for all epochs and it's one of the fundamental time scales recognized by the IAU. For older epochs where TAI is not defined, TT is effectively the same as the historical ephemeris time (ET). For the epochs where TAI is defined, it is a simple offset from TAI (and GPS time). Another reason I like TT is all other common time scales can be directly related to it (and we should give the references for those relationships in the documentation). However, we should make clear in the documentation that if the user consistently specifies the Julian day number or broken down time using the UTC offset (assuming the plot does not include a leap second so that a unique UTC offset can be defined), GPS time offset, or TAI offset, then the broken-down time variable of the plot will be expressed in UTC, GPS time, or TAI as well. That removes the need to provide a user flag for what kind of offset is being used which is great from the KISS point of view. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------- 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
