Re: [Plplot-devel] New test script

[Jerry <lan...@qw...>]

On Aug 18, 2008, at 5:04 PM, Alan W. Irwin wrote:

> 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.
>
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.

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