On Fri, Nov 23, 2007 at 10:24:18AM +0100, Arjen Markus wrote: > Alan W. Irwin wrote: > > >I was interested enough so I googled for strftime. strftime appears > >to be a comprehensive time formatting routine that would be a good to > >use. There is even a "poor man's version" that you could use > >from http://www.perlmonks.org/?node_id=290054. > > > >Anyhow, I think you have a good idea. > > > 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. > > Still, having a date/time type axis will be a good thing! It will enable us > to implement a number of "financial" plot types, for instance (see a > question > on the list from may/june this year).
I've also used julian day for work related stuff (often just day within the year). As you say, this gives a wider range of dates. For compatibility with all the other plotting routines we will have to store the date as PL_DOUBLE internally, and so it perhaps makes sense to use the julian day, rather than number of seconds which is usually stored as a 32-bit integer. The 32-bit integer breaks down about 2038 when we need to switch to a 64-bit integer. I'm sure by then 64-bit computing will be ubiquitous. Anway, for now, perhaps being limited to 1970-2038 is a little restrictive for a plotting library. My other thought (more work, but more flexible) is to use something like the julian day or number of seconds, but allow you to define your own epoch. For example, often you know what day of the year it is, or hour of the day. By setting the epoch to the start of that year or day you avoid the user having to explicitly calculate the number of years since some distant epoch. Alternatively we could supply routines to do this calculation. The other advantage of this is that it keeps the julian day small and increases the number of decimal places and hence the time resolution. This might be important for those wishing to plot millisecond data. Algorithms for calculating julian day <-> yy/mm/dd hh:mm:ss are relatively simple so this is not a coding problem. More complicated is the code for parsing the output template - which is where strftime would have come in useful. Andrew ------------------------------------------------------------------------- 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
