On 2007-11-23 10:24+0100 Arjen Markus wrote: > Alternative representations of date and time could be Julian dates > (effectively > the number of days, time as a fraction, since well before Christ). The > advantage > of that is that the definition is platform-independent, which is not the case > for > the number of seconds since "epoch" - ubiquitously but not universally chosen > to be midnight, 1 january 1970. Another advantage is that the valid range is > much larger than that for the number of seconds (if stored as a 32-bits > signed integer): > - Julian dates range from effectively the beginning of time to Armageddon, > as they are stored as double precision reals (resolution is slightly more > than milliseconds, IIRC). > - The date/time as seconds since 1 january 1970 ranges from 1903 to 2037 > (IIRC) > > The drawback is that you will have to write more code (I am not aware of > strftime()-equivalent for Julian date/time, but there might be). And perhaps > the API will be more involved - dealing with the Gregorian calendar > more explicitly. But there are good algorithms to do these conversions. >
Hi Arjen: I do have some concerns about your idea which I hope Andrew will consider before making his final decision. If Andrew uses the (local) C library time_t variable convention then that same (local) C library can be used to convert the user's specific time representation into the time_t representation. Using some representation other than time_t puts an extra burden on both Andrew and each user. The C library internal representation of time as a time_t variable does have the well-known drawback you mentioned of a rather limited date range for those systems where time_t is defined as a 32-bit integer, see discussion in http://en.wikipedia.org/wiki/Year_2038_problem . Note, however, hardware is rapidly moving to 64-bit right now. For example, my impression from a recent computer buy is that 64-bit has become the norm rather than the exception for new PC's. Thus, on PC's at least, I don't think the above 32-bit time_t issue is going to be relevant for too much longer. In the past for long time series, I have used special programming to convert my particular time representation to Julian day number, and then plotted that Julian day number as the independent variable. Those who are stuck with 32-bit time_t and who want to plot a time series outside the 32-bit time_t limits can always ignore Andrew's new time API fall back to using this approach. I guess my principal concern is various vendors (both Unix/Linux/Mac OS X vendors and the one windows vendor) have tried to struggle with time representation issues for years. Does Andrew want to wade into that tarpit? I just think it would be easier for him (and users) if he just adopted whatever convention the local C library used for time_t. But the decision is, of course, up to Andrew since he is the one volunteering to do the coding. 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: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
