On 2009-02-18 14:11-0000 trc wrote: > Hi, > > > Arjen Markus wrote: > >> I have found the same problem with setenv() and unsetenv() on my >> venerable platform (Windows XP, 32 bits, with MSVC 6.0). I will create >> a workaround using putenv(), because right now building PLplot stops >> on the QSAS test program. >> > > In case you haven't created the work round (and apologies for not sending it > earlier) please find a limited patch for implementing setenv for MSVC. > > This patch does not use CMake to configure the optional code instead relying > on Compiler and in source Macros for configuration. >
Thanks, Terrence, for this setenv patch for MSVC. Arjen, I would appreciate it if you review this patch to make sure it works for all Windows cases and then commit it. That should at least allow the windows build (originally broken by me, and sorry about that) to work again. There is some urgency to the commit because some additional Windows users beyond you and Werner are attempting to build from our svn version. > With this patch MSVC 2008 version of qsastime[_testlib] produces > > > sizeof(time_t) = 8 > sizeof(int) = 4 > 0xffff > Test 01 of calendar dates in the vicinity of the JD epoch > > Start of Julian proleptic inner test > input and output (strfMJD) date/time > -4717-01-01T12:00:00.000000000000000Z > -4717-01-01T12:00:00.0Z > setFromUT JD = -1826.0000000000000000 days > Start of Gregorian proleptic inner test > input and output (strftime), and output (strfMJD) date/time > -4717-01-01T12:00:00.000000000000000Z Comparison with qsastime_testlib.out_standard shows all is well up to here except for the above 0xffff which I assume is a spin-off of trying to put 0xffff on stdin for the programme on Windows rather than the echo 0xffff | lib/qsastime/qsastime_testlib method that works on Linux. > setFromUT secs_past_epoch = -211021243200 seconds To double-check this calculation (which does not appear on qsastime_testlib.out_standard since that Linux calculation had no errors), MJD = JD - 2400000.5 so the Gregorian epoch JD (from qsastime_testlib.out_standard since you didn't get that far) of -1788 corresponds to MJD = -2401788.5 days since the MJD epoch. But the Unix epoch of 1970-01-01 has an MJD of 40587 so this corresponds to -2442375.5 days since the Unix epoch or -211021243200.0 seconds since the Unix epoch which confirms the above calculation. > my_timegm secs_past_epoch = -1 seconds That is the source of the error. On your platform, my_timegm only works as well as the C library mktime routine which currently claims that 4718-01-01 BCE (Gregorian proleptic calendar) is only 1 second before the Unix epoch of 1970-01-01. So once your patch or something similar is applied, the next step is to see if there are any Windows platforms where mktime gives a correct result for years before the Unix epoch. > delta secs_past_epoch = -567845695 seconds This does not represent the difference of the two previous time_t values like it should. I have now fixed (revision 9549) the output formatting so the resulting difference of time_t values reported here can have time_t range rather than int range (which overflowed in this case giving the bad delta secs_past_epoch result above). In sum, the next step here is to get the patch tested, revised (if necessary), and committed as a matter of some urgency since it makes the windows build work again. The next step after that is to try and find some windows platform where mktime (and therefore my_timegm) works for epochs before the Unix epoch. 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 __________________________ ------------------------------------------------------------------------------ Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
