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
> the number of days, time as a fraction, since well before Christ). The
> 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
> 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
> 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
> 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
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
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.