On 2008-08-18 16:04-0700 Jerry wrote: > On Aug 17, 2008, at 11:43 PM, Andrew Ross wrote: >> >> Jerry, >> >> I'm not quite sure what your latest commit is intended to do? It >> certainly doesn't reproduce the C results for me. >> >> The plplot time functions use 0.0 to represent January 1, 1970. >> This is >> the usual unix convention for the epoch in C time functions. You have >> set xmin to be 0.0 by subtracting 2 identical times from each other, >> hence the label you see. Is this really what you see with the C >> version >> of the example as well? > > Yes. x29c labels the first major tic as 1970-01-14 and it is 14 minor > tics to the right of the left side of the plot. Three additional > labeled tics are at 1970-01-28, 1970-02-11, and 1970-02-25. > > The tweaks that I made in my latest commit cause the generated PS > code from both Ada examples to match that from the C example. > > Maybe there is something wrong with the C time functions on OS X. > >> >> The C version is complicated because the C time functions are rather >> unhelpful when it comes to timezones. The example is designed to be in >> UTC (Universal coordinate time). This is the norm for scientific >> applications to avoid problems with synchronising measurements made in >> different locations. Anyway, the C functions mostly work in the local >> time zone. What we want is to turn a time broken down into year, >> month, >> day, hour, min, sec into a time in seconds since January 1 1970. To >> achieve this using POSIX functions you have to set the timezone to be >> UTC (by setting the TZ variable and then calling tzset). The call to >> mktime (which uses the time in the current time zone) will then assume >> time in UTC rather than local time. This is not particularly pretty >> and >> may not work on Windows platforms (testing appreciated!) >> >> Is there any way in ada to convert a broken down time (in UTC) into a >> time in seconds since Jan 1 1970? From a brief look at the gnat >> manuals >> it seems that ada time functions are also rather muddled when it comes >> to time zones. > > I have not studied the GNAT manuals or the Ada Reference Manual in > detail wrt the time functions. (BTW, there are probably GNAT calendar > functions that extend the Ada-specified calendar functions. The > function that I am using, Time_Of, is standard Ada and not a GNAT > extension.) The method that I am using seems to me to be time-zone > agnostic, or rather, assumes the same time zone in all calculations. > I think that that should work for this example. > > There appears to be support for many time functions, including leap > seconds, in Ada.Calendar.Time_Zones, http://www.adaic.com/standards/ > 05rm/html/RM-9-6-1.html, but since the PLplot example should work > assuming that the time zones are the same for all dates, there should > be no need to use any of the fancy stuff.
Local time includes "daylight savings" shifts as discussed previously on this list so politicians sometimes screw up your above assumption for certain epochs and locales. tstart is the number of seconds between two _UTC_ epochs to avoid such problems. This is commented pretty well in the C code. /* tstart is a time_t value (cast to PLFLT) which represents the number * of seconds elapsed since 00:00:00 on January 1, 1970, Coordinated * Universal Time (UTC) on 2005-12-01 (UTC). */ As somebody pointed out earlier, daylight savings was in effect for 1970-01-01 while not in effect for 2005-12-01 in Britain. Thus, if you use local time in example 29 rather than UTC, British residents get a different (wrong) result than those without a daylight savings time change between the two epochs. Politicians love to fiddle with daylight savings as illustrated for the case of daylight savings in Britain for the 1970-01-01 (winter) epoch. Therefore, the only safe thing to do for all locales is to use UTC for both epochs which is what the C code does now. You should do the same for the Ada case, and it looks like that will be quite possible from the Ada.Calendar.Time_Zones reference you gave above. By the way, the current Ada example 29 gives a result that is different from the C result for my locale using Linux. But unlike Andrew's case, for my locale there is no daylight savings shift between the two above UTC epochs. Thus, the difference I see must be due to some other issue than the daylight savings one mentioned above. I believe this additional issue is a recently introduced one because I think the Ada example 29 results were previously agreeing with the corresponding C result here. 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
