Re: Possible bug in 6.2?

[Jonathan Callahan <Jonathan.S.Callahan@xxxxxxxx>]

Phil,

It looks like there might be bug and a 'feature' at work here.  First let me describe what is going on generally.

• The XML configuration file allows you to specify specific values for the time axis. (As you are trying to do.)
• These values should be presented in the user interface exactly as they are specified.
• These values are processed when the user interface is created.  The resulting HTML will create a widget with lines like:
      <option value="15-Nov" >15-Nov</option>
• The display string should be exactly what you specified while the value will vary as explained below.
  
• In the product server, the the incoming values are processed.
  
• The processed values are used to specify a Ferret time region using either
  
• "T=~date string~" or
• "L=~index number~" or
  
• "T=~numeric time~"
  

In LAS version 6.2 we modified the perl code that generates the UI (las/xml/perl/LASServlet.pm) and that handles interaction with Ferret (Ferret.pl) to use a single module for processing date strings -- las/xml/perl/TMAPDate.pm.  It is the job of this module to recognize as many valid date strings as possible.  Here is the list:

Supported formats:
  YYYYmmDDHHMMSS
  YYYY-MMM-DD
  MMM-DD-YYYY
  DD-MMM-YYYY
  YYYY-MMM-D
  D-MMM-YYYY
  YYYY-mm-DD
  YYYY-mm-D
  YYYY-m-DD
  YYY-mm-DD
  YYYY-m-D
  YYYYmmDD
  YYY-m-DD
  YY-mm-DD
  YYY-m-D
  YY-mm-D
  YY-m-DD
  Y-mm-DD
  Y-mm-D
  Y-m-DD
  DD-MMM
  Y-m-DD
  MMM-DD
  Y-m-D
  D-MMM
  MMM-D
  MMM

Except for the first format, each may be followed by a time (i.e.  " 00:00:00").  Currently there is no support for time zones.

We need to look into the code that generates the interface as your report indicates that there is a bug there.  But "some strings work and others don't" is a feature.  Here's the logic:

1. If the string is a valid date according to TMAPDate.pm, LASServlet.pm will create a time widget where the return value is equal to the display string specified in the XML..
2. The same will happen if the string is not a valid date but is a valid integer.
3. If the string is neither of the above, the return value will be the index of the display string.

This logic reflects what is happening on the product server side of things where the value string will be used to set a region in Ferret.

1. If the string is a valid date according to TMAPDate.pm, Ferret.pl will use the associated Ferret style date string with "T=..." to set the time range.
2. If the string is not a valid date but is an integer it will be used with "L=..."
3. If the string is neither of the above it is presumed to be a float and will be used with "T=...".  (This is necessary to support modelers where the time axis is often fictitious and the numeric time is meaningful where a date is not.)

Sorry about the overkill explanation but at least now we'll be able to find this info when we go to fix the bug.  I've put this bug into Bugzilla (our bug tracking system) and I hope it will be fixed in the next release due out at the beginning of April.  (Any takers for this one?)

Thank again for the detailed bug report.


-- Jon


Phil Moses wrote:

Hello,
After upgrading to LAS 6.2, we have seen some strange behavior with the
elements in a time axis. Please see the described problem below, we have
found a work around for the time being but for the future we are
attempting to determine is this something that was done incorrectly on
our end or is this a possible bug in the newest software?
-----------------------------------------------------------------------------
<begin problem Description>


So we were using the string version as an index into the l axis that has
4 elements for the following example:

     <jpl_time_ad_yearly_mean units="hours" type="t">
        <v>year 1997</v>
        <v>year 1998</v>
        <v>year 1999</v>
        <v>year 2000</v>
     </jpl_time_ad_yearly_mean>

and now this yields an incorrect time axis and I cannot access the data.

If I change it to a real time and do not use the string:

     <jpl_time_ad_yearly_mean units="years" type="t">
       <v>01-JAN-1997</v>
       <v>01-JAN-1998</v>
       <v>01-JAN-1999</v>
       <v>01-JAN-2000</v>
     </jpl_time_ad_yearly_mean>

Then the code does work and correctly find the data sets, but since this
is a mean
we would prefer not to have explicit dates.  Also if I use the index
alone:

     <jpl_time_ad_yearly_mean units="years" type="t">
       <v>1</v>
       <v>2</v>
       <v>3v>
       <v>4</v>
     </jpl_time_ad_yearly_mean>

then the code does work correctly but is not informative at all.

What is even stranger is the following does the correct string indexing
problem an now displays the string and the correct index:

     <jpl_time_ad_yearly_mean units="years" type="t">
       <v>1997 annual mean</v>
       <v>1998 annual mean</v>
       <v>1999 annual mean</v>
       <v>2000 annual mean</v>
     </jpl_time_ad_yearly_mean>

Although it logically makes no sense why some "strings" work and
others don't 


I also have a single field string index that is also not referencing
correctly, so I 
had to double the entries and only the first one will work correctly:

      <jpl_time_ad_mean units="years" type="t">
       <v>1997 to 2000</v>
       <v>1997 to 2000</v>
      </jpl_time_ad_mean>

this should be:

      <jpl_time_ad_mean units="years" type="t">
       <v>1997 to 2000</v>
      </jpl_time_ad_mean>

But that does not even show a time index and will not allow you
to correctly get to the data.
------------------------------------------------------------------------------
<end problem description>


Any insight is greatly appreciated.
Thanks,
Phil Moses