On Aug 18, 2008, at 5:04 PM, Alan W. Irwin wrote:
Yes, the Ada and C versions previously agreed. And it was the Ada calendar that found the 3600 second error in some of the bindings that had hard-wired the time offset in example 29.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 isthe usual unix convention for the epoch in C time functions. You haveset 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 ratherunhelpful when it comes to timezones. The example is designed to be inUTC (Universal coordinate time). This is the norm for scientificapplications to avoid problems with synchronising measurements made in different locations. Anyway, the C functions mostly work in the localtime 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. Toachieve this using POSIX functions you have to set the timezone to beUTC (by setting the TZ variable and then calling tzset). The call tomktime (which uses the time in the current time zone) will then assumetime 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 atime in seconds since Jan 1 1970? From a brief look at the gnat manualsit seems that ada time functions are also rather muddled when it comesto 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 onthis list so politicians sometimes screw up your above assumption forcertain epochs and locales. tstart is the number of seconds between two _UTC_ epochs to avoid such problems. This is commented pretty well in the Ccode./* 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 for1970-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 previouslyagreeing with the corresponding C result here.
As I see it, the first thing that has to be reckoned with is why x29c.c is mislabeling the axis on OS X. I've pasted a screen shot as a PDF but I suppose it won't survive the list mail process.
Jerry
pastedGraphic.pdf
Description: Adobe PDF document
------------------------------------------------------------------------- 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
