PLplot

Arjen Markus wrote:

>Hello,
>
>can anyone comment on the available range for the date/time axes?
>I ask because of the wish to plot dates before 1970, the typical
>epoch year, as expressed in 
>https://sourceforge.net/tracker/index.php?func=detail&aid=1743004&group_id=2915&atid=352915.
>
>I checked the definition of time_t on my Linux system: it is a 
>four-bytes integer, so the
>range is roughly from 1904-2036.
>
>How can we go beyond this range? Do we have to use a 64-bits machine?
>  
>
Hm, my question is not meant as a complaint. I am just wondering how we 
can cope
with the (in my view) legitimate question about support for plotting 
historical data.

Regards,

Arjen

Hi Arjen,

We had this discussion when I first implemented the date / time
functions. It is a trade off between using the widely available system
routines (with their limitations) and supporting our own set of date /
time formatting routines with an associated large overhead on the
developers. Of course in the long term 64-bit will solve many of the
problems. 

In the intermediate term there are often solutions. If you are plotting
over many years and just formatting the year, then you may well not need
to use the date / time formatting at all. 

If you are working over a shorter range of dates / times and don't need
the year, then it doesn't actually matter what year you choose. Example 
29 illustrates this. (Just be careful about leap years). Also, you can
always format the year as a two digit year (%y, %g), and so the exact 
century doesn't matter.

The only easyish way around this I could think of which still retained
second accurancy would be to allow you to specify the epoch (i.e. the
date / time which corresponds to t = 0). We'd still need our own
implementation of strftime to actually use this though.

Andrew

On Fri, Feb 29, 2008 at 08:55:30AM +0100, Arjen Markus wrote:
> Hello,
> 
> can anyone comment on the available range for the date/time axes?
> I ask because of the wish to plot dates before 1970, the typical
> epoch year, as expressed in 
> https://sourceforge.net/tracker/index.php?func=detail&aid=1743004&group_id=2915&atid=352915.
> 
> I checked the definition of time_t on my Linux system: it is a 
> four-bytes integer, so the
> range is roughly from 1904-2036.
> 
> How can we go beyond this range? Do we have to use a 64-bits machine?
> 
> Regards,
> 
> Arjen
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Andrew Ross wrote:

>Hi Arjen,
>
>We had this discussion when I first implemented the date / time
>functions. It is a trade off between using the widely available system
>routines (with their limitations) and supporting our own set of date /
>time formatting routines with an associated large overhead on the
>developers. Of course in the long term 64-bit will solve many of the
>problems. 
>
>In the intermediate term there are often solutions. If you are plotting
>over many years and just formatting the year, then you may well not need
>to use the date / time formatting at all. 
>
>If you are working over a shorter range of dates / times and don't need
>the year, then it doesn't actually matter what year you choose. Example 
>29 illustrates this. (Just be careful about leap years). Also, you can
>always format the year as a two digit year (%y, %g), and so the exact 
>century doesn't matter.
>
>The only easyish way around this I could think of which still retained
>second accurancy would be to allow you to specify the epoch (i.e. the
>date / time which corresponds to t = 0). We'd still need our own
>implementation of strftime to actually use this though.
>  
>
Yes, I remember this discussion :). I had not realised the workarounds 
you mention,
but they seem promising enough. I will add your answer to the SF request 
(so that
it is immediately accessible to the OP).

Regards,

Arjen