On 2008-11-19 16:02-0000 Andrew Ross wrote: > On Wed, Nov 19, 2008 at 10:19:39AM +0000, Steve Schwartz wrote: >> Andrew/Alan, >> >> On Wed, 2008-11-19 at 10:02 +0000, Andrew Ross wrote: >>> One other thing it would be nice to finalise before a release is what >>> we >>> are going to do with the date / time handling. I know there was a lot >>> of >>> discussion about this but we never came to a firm conclusion. If it >>> doesn't make it into the next development release then fair enough, >>> but >>> we really should finalise the API before the next stable release. >> >> This one is waiting, I believe, routines that we promised to deliver to >> handle time. It is still my intention to deliver these, but we have been >> pushing hard to get a new release out of our own QSAS software and I >> can't see getting something to you within a week or two that could then >> be properly tested and integrated. Likewise we have promised a native Qt >> driver (which we have fully functional within our own software but >> haven't extracted and bundled yet. Again this won't happen on a >> timescale of weeks due to our other commitments. >> >> Re date/time handling: for the present we are using the patch I sent >> some time ago to you that implements a robust mktimeutc avoiding the >> idosyncracies of C's insistance on providing a mktime routine tied to >> local time. It would be possible for you to include that patch in your >> release, although you will need to modify the relevant examples and >> perhaps documentation to reflect the appropriate usage. The patch itself >> is pretty simple. >> >> I'm sorry that after a flurry of activity we haven't completed the >> above, but it's down to priorities and resource management. >> >> On the positive side, we will soon release a major piece of software >> that utilises plplot and demonstrates its power. I'll send you a link to >> the beta versions soon in case you want to have a look... > > Steve, > > I understand your other pressures. In the long term we would like to see > a proper solution to this problem. In the interim perhaps it is just > best if we mark this facility as experimental and likely to change in > future releases. We try to avoid API changes where possible, so it would > certainly be nice to have the final(?) version in place for the next > stable release, but this is probably not in the imminent future. We > could integrate your mktime patch for the present as a work-around. > Alan - do you have any thoughts? > > I am quite happy to help with the testing and integration of any code > into plplot if that helps. > > The native QT driver would be a very nice feature - but is less pressing > in the sense that it does not impact on the rest of the library or lead > to any API changes.
Hi Andrew: I have just reviewed some of our previous off-list discussion with Steve about date/time, and here is what I hope is a fair summary of the consensus that was achieved. Steve's group would deliver three functions. (1) a robust replacement for mktime which would take broken down time and transform it to time-epoch as a double-precision variable. (2) The inverse of (1). (3) a robust replacement for strftime. All three functions would be in our public API and all three would completely ignore leap seconds (which I finally realized added horrible complexity which we wanted to avoid). Once these three functions were delivered by Steve's group, we would integrate those into PLplot with the ability to get/set a PLplot time epoch which if chosen wisely by the user for the particular time range being plotted would give outstanding numerical precision for time-epoch stored in a double-precision variable. The implementation of the three functions has been delayed according to what Steve said above. A preliminary patch for (1) has been delivered, but I prefer not to work on its integration into PLplot until after the present release when presumably (2) and (3) will be delivered along with possible additional changes to (1). For this release, I suggest we simply go with what we have in svn trunk for date/time and ignore for now the preliminary implementation of (1) that is available. Andrew, assuming you agree with this plan, I have put a warning into README.release (revision 9001) about our future plans for date/time and the API changes that should occur because of that. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/plplot-devel
