Andrew/Alan,
Thanks for picking up this thread. I think your remarks are all sensible.
We have code and experience in going back and forth from broken-down time to
time since an epoch and I think we should be able to bundle that and supply it
as pltimeutc and its inverse. Give me some time to discuss with my colleagues
and we'll come up with a concrete proposal for a struct pltm.
This will certainly include a non-integer seconds field, and all the recent
approaches we've seen to handle time accurately as a continuous variable resort
to two variables (e.g., Alan's suggestion of seconds and fractional seconds).
However, plotting (as opposed to ticks and labels) requires a single variable,
so there will need to be some strategic thinking here.
I don't think there is a universal agreement on a Unix epoch, so we would use
one of our own. Since we're talking about a self-contained implementation of
time routines, that choice doesn't matter as long as we stick to our own
routines.
We don't deal with leap seconds. As long as we use our own routines to get from
broken-down time to epoch time and back, the result is clean and consistent,
although this means we only allow a minute to have 60 seconds. Thus a time
series that actually spans across a leap second will be short by a second, but
if all the times are calculated from broken-down times every point outside the
leap second will be at its correct time. [All these approaches are borrowed
from NASA CDF routines, although we've changed them to count in seconds rather
than milliseconds.]
In terms of time formatting, I had originaly thought we could just retain
strftime to do the work by copying the entries from a pltm struct into a tm
struct; that may be a short-term solution, but I think we should bite the
bullet and divorce ourselves from the C-routines. From our broken-down time it
is relatively easy to format year, month, day, hour, minute, second, ...
strings, and also day-of-year (1-366) all as numbers. Converting month into a
name is easy (it's an example in Kerrigan & Ritchie I believe). Weekdays and
week numbers are new to me; I'm not sure plplot needs them. In any event, woudl
could hack a source code for strftime (which parses the format string and
pickes what it needs from tm) or otherwise do this ourselves.
I don't think any of the above would require much if any maintenance once
tested (famous last words!).
Of more concern to me would be to ensure that the ticks and labels are
accurate, i.e., that the alogrithm to decide where to put a tick based on the
input continuous time variable will actually put it at, say, 3:00:00.000. And
(as I commented a few weeks back) that default tick/sub-tick intervals are as
nice as possible (the present algorithms will put ticks at 50 minute intervals,
for example. 50 is obviously a nice number if the units are meters, but not
minutes or seconds. What to do for days is less clear, especially if the
labelling is in weeks.)
OK I'll stop there. We'll have some internal discussions here and get back to
you. If you reply to all, my colleagues will see any further comments anyone
has.
Regards,
Steve
+-------------------------------------------------------------------+
Professor Steven J Schwartz Phone: +44-(0)20-7594-7660
Space and Atmospheric Physics Fax: +44-(0)20-7594-7772
The Blackett Laboratory E-mail: [EMAIL PROTECTED] <mailto:[EMAIL
PROTECTED]>
Imperial College London Office: Huxley 6M70
London SW7 2BW, U.K. Web: http://www.sp.ph.ic.ac.uk/~sjs
<http://www.sp.ph.ic.ac.uk/~sjs>
+-------------------------------------------------------------------+
________________________________
From: Andrew Ross [mailto:[EMAIL PROTECTED]
Sent: Tue 02/09/2008 8:20 AM
To: Alan W. Irwin
Cc: Schwartz, Steven J; PLplot development list
Subject: Re: [Plplot-devel] time
Steve, Alan,
I entirely agree that the only sane, cross-platform and cross-language
way of dealing with the timegm (and possible gmtime) problem is to add our
own implementation. This is relatively straightfoward and I can see no
reason not to. The bigger question is whether we carry on using
strftime. Systems with limitations in gmtime (like no negative values
for time_t) are likely to be limited with respect to strftime as well.
Replacing and maintaining this is a much bigger job though.
Andrew
On Mon, Sep 01, 2008 at 10:59:23PM -0700, Alan Irwin wrote:
> Hi Steve:
>
> Since this is a broader topic, I have changed the subject line.
>
> On 2008-09-02 02:14+0100 Schwartz, Steven J wrote:
>
> > Alan,
>
> > Your approach in example 29 is to use the TZ environment variable to trick
> your computer into thinking that it is in a UTC timezone. This doesn't work
> on all platforms, hence your ifdef for Windows.
>
> To explain some background here, I was following the POSIX-compliant
> approach recommended as an alternative to timegm by the timegm man page on
> Linux. That said, I think we agree our example programs should demonstrate
> the best methods if at all possible, and I am not particularly happy with
> this POSIX-compliant method for obtaining UTC time in seconds since the Unix
> epoch from broken-down time. For one thing, it appears not to work for
> Jerry's Mac OS X platform for unknown reasons, and you have mentioned some
> other reasons as well which I largely agree with.
>
> > An alternative approach, which I offered in a (small) patch several weeks
> back, is essentially a private and totally portable implementation of
> timegm, which I called mktimeutc, that lives inside plplot - but which
> could/should be made available to the end user. This guarantees that the
> plplot time axis handling will behave itself and that the end-user has a
> consistent way to construct and break-down a calendar time.
>
> We have dealt with a similar issue recently with random numbers, and in the
> end we decided to embed our own small high-quality random-number generator
> into our C library with that generator available for each of our language
> bindings to give us uniform results for all languages and as a general
> service to our users who often do need access to high-quality RNG's.
>
> I think we should follow a similar approach with UTC, but aim for the
> absolutely best algorithm possible with none of the limitations of the
> POSIX algorithms.
>
> If no core developer objects to that idea, then I have some ideas about how
> this should be implemented.
>
> (1) Rename mktimeutc as pltimeutc to be consistent with the rest of our names.
>
> (2) I haven't actually looked at that routine yet, but I think we should
> carefully review the argument list and what is returned.
>
> I would favour representing broken-down time as yyyy, mmmm, dddd, hhhh,
> mmmm, ssss, where the first 5 arguments are integers and the last double
> precision. And I think we should store the result (seconds since the Unix
> epoch) as two additional double precision arguments where the first one
> represents the integer number of seconds since the epoch (and which is
> therefore exact for a huge range of epochs) and the second one a fractional
> remainder. As a result this would be a void function.
>
> (3) I think we need a plutctime void function as well to be the exact
> inverse of pltimeutc with essentially no range limitation (unlike gmtime)
> and using the same argument list (perhaps in different order) as pltimeutc.
> Do you have access to such code, and if so, would you be willing to
> donate it to PLplot?
>
> (4) Thoroughly test plutctime to make sure it delivers the same result as
> gmtime within the latter's range limitations, and thoroughly test pltimeutc
> to make sure it reliably delivers the inverse of plutctime.
>
> How do you handle the leap-second problem for the current mktimeutc? Do you
> ignore leap seconds altogether (which is probably not a good idea) or do you
> have a table of leap seconds within the routine?
>
> (5) Assuming pltimeutc and plutctime pass all our tests, make them part
> of our public C library API and make them available for each of our language
> bindings so that we no longer have to adopt hard-coded constants for
> example 29 for any language and also as a service for our scientific
> users who deal with plotting of time series.
>
> Before any core developer complains about reinventing the wheel, I am
> concerned about that issue as well, but I think our recent experience with
> example 29 shows that the C library does a horrible job of dealing with UTC,
> and that is true for some of the other computer languages as well. Thus, I
> think it is a good idea for PLplot to step forward to fill this gap
> uniformly for all our language bindings to the benefit of our users who are
> concerned with plotting time series.
>
> 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
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>
-------------------------------------------------------------------------
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
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
