Alan,
If I may be allowed to widen this discussion from Ada to "time," I still think
there are underlying issues that should at least be discussed. As I said a few
weeks back, we have a vested interest in this matter because time plays a
critical element in data from spacecraft, and because we write analysis/display
software that we ship to innocent end-users running on various platforms.
The issue stems from the combination of your sensible strategy to take
advantage of C's capabilities to format time strings and basically handle time
(at least between 1970 and 2038) with C's complete failure to provide the
inverse to gmtime. Users are forced to confront local time which not only has
the complication of Daylight Savings Time, but also of course real time zones
(testing in the UK is dangerous; try setting your TZ to EST and re-run various
tests).
The inverse of gmtime is timegm, but it is not part of the standard and not
portable, so let's ignore it.
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. It has a few other drawbacks:
1 It requires the end-user to remember to do this everytime, something that is
more problematic for the person who uses plplot from time to time for their own
purposes, but nonetheless not ideal
2 It hardcodes ugly numbers (1133395200) that are easy to mis-type and that
assume a rigid epoch standard, at least in a platform-specific way.
3 I think it is not multi-thread safe and also can have side-effects. In
particular, if the user forgets to reset TZ back to their proper local timezone
(or at least unset the environment variable), time handling by the rest of the
process running in the same shell will be wrong. This can have disastrous
consequences for file creation timestamps at the very least, and perhaps child
processes that watch each other.
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.
Perhaps this approach would cause problems for some application that genuinely
wanted to work in local time. I can't imagine such an application that couldnt
simply pretend it was in UTC (e.g. by grabbing the broken-down tm structure in
local time and then using mktimeutc which would ignore the timezone and DST
flags). I'll admit, though, that end-users never fail to surprise me with ways
of using our software that I never dreamt of - sometimes to very good advantage!
Let me be clear. I'm not out to proclaim or insist that my approach, and patch,
are the best/only way forward. And we can find a way 'round whatever way is
finally adopted (though I hope that won't be by simply constantly applying our
own patch to our version of plplot). I merely saw this discussion as a case in
point where others might wish to consider the alternatives.
We are enjoying (?) moving our software from pgplot (which btw has a very good
set of algorithms for automatic sub-ticks on time axes) to plplot. And we (more
correctly our chief programmer Alba Rochel) is nearing completion of a native
Qt driver for plplot that he will no doubt deliver to you. This may not only
offer Qt application-writers something useful, but also provides an alternative
to X11, with the ability to dump to various image formats (bitmap and vector I
believe)directly from Qt.
Yours
Steve
PS At the expense of more code writing, it would be straightforward to dispense
with C's time handling altogether and use a totally private (and portable) time
reference to go from broken-down times to times from your own epoch. This has
the advantage of being in your control, and hance being able to avoid the
pitfalls of 1970-2038 time ranges. It would also generate more efficient code I
think, at the expense of re-inventing the generic time formatting routines.
Much of that exists (e.g., the CDF Epoch time handling routines from NSSDC - on
which my patch code is based). Not sure I'd jump that way just yet if I were
you, but it depends how deep into the crystal ball you want to gaze in terms of
portability and future-proofing.
+-------------------------------------------------------------------+
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: [EMAIL PROTECTED] on behalf of Alan W. Irwin
Sent: Tue 02/09/2008 12:10 AM
To: Jerry
Cc: PLplot development list
Subject: Re: [Plplot-devel] Time calculation in Ada example 29
On 2008-09-01 14:58-0700 Jerry wrote:
> Andrew,
>
> Does the Ada example, with xmin hardcoded to 1_133_395_200.0,
> generate the same Postscript as the C example?
The current Ada example 29 code has
xmin := 1133395200.0;
(no underscores), and yes, that hard-coded value gives identical results to
the C example which is implemented in UTC to avoid anomalies in daylight
savings time that occur for such locales as the UK. Both the Python and Java
examples are implemented in UTC for the same reason.
So Jerry, either settle for the current hard-coded value or else implement
the Ada time calculations for example 29 in UTC. Local time just doesn't
cut it.
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
