AdvancedCriteria.convertRelativeDates() notEqual RelativeDate $today

[stonebranch2]

Hi Isomorphic,

We have the following JSON formatted AdvancedCriteria.

   {
      "_constructor":"AdvancedCriteria", 
      "operator":"and", 
      "criteria":[
          {
              "fieldName":"launchTime", 
              "operator":"notEqual", 
              "value":{
                  "_constructor":"RelativeDate", 
                  "value":"$today"
              }
          }
      ]
  }

On the client, the relative date criteria is converted to the following.

       data:{
          operator:"and", 
          criteria:[
              {
                  operator:"not", 
                  criteria:[
                      {
                          operator:"betweenInclusive", 
                          fieldName:"launchTime", 
                          start:"2016-07-19T04:00:00.000", 
                          end:"2016-07-20T03:59:59.999"
                      }
                  ]
              }
          ]
      }

On the server, the JSON formatted AdvancedCriteria is converted to an AdvancedCriteria object using AdvancedCriteria.decodeClientCriteria(String).

AdvancedCriteria:[and:[{launchTime notEqual {_constructor=RelativeDate, value=$today}}]]

However, when the relative date criteria is then converted using AdvancedCriteria.convertRelativeDates(), it is not performing a conversion consistent with the client above, resulting in inconsistent server-side report data.

 
  AdvancedCriteria:[and:[{launchTime notEqual java.util.GregorianCalendar[time=?,areFieldsSet=false,areAllFieldsSet=false,lenient=true,zone=sun.util.calendar.ZoneInfo[id="America/New_York",offset=-18000000,dstSavings=3600000,useDaylight=true,transitions=235,lastRule=java.util.SimpleTimeZone[id=America/New_York,offset=-18000000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3,endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]],firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=?,YEAR=2016,MONTH=6,WEEK_OF_YEAR=?,WEEK_OF_MONTH=?,DAY_OF_MONTH=19,DAY_OF_YEAR=?,DAY_OF_WEEK=?,DAY_OF_WEEK_IN_MONTH=?,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=0,MILLISECOND=?,ZONE_OFFSET=?,DST_OFFSET=?]}]]

The same applies for $yesterday, etc.

Thanks

SmartClient Version: v10.1p_2016-06-09/Pro Deployment (built 2016-06-09)

[Isomorphic]

Just a note that we are looking into this and will post an update on this thread when we have investigated

[Isomorphic]

We have committed a fix for this in SmartGWT 5.1 and greater. The issue here is that the server-side API AdvancedCriteria.convertRelativeDates() does not have access to the same context as the equivalent client-side, which is implemented as a DataSource instance method. This is fixed by providing a new version of convertRelativeDates() that accepts a DataSource in its parameters. You should switch to using that API to get correct results in all use cases, although in this particular case - where you want the value to be treated as a datetime, not a logical date - the default handling will do what you require.

Note, there is a further issue here: the server does not know what timezone the client is running in, so its idea of what "today" means is going to be different from the client's unless they are in the same timezone. We can see that this may well be an issue in your case - the "$today" criteria sent up from the client shows that the server and client are 4 hours apart, so presumably the client is in US Eastern and the server is in UTC. We are going to implement a new facility so that the client can include a timezone with relative date definitions, to bridge this discrepancy. However, this will probably only be added to the current development branch (6.1); it is not likely that we will port this new facility back to bugfix branches.

[stonebranch2]

Thank you,

We will verify when the nightly containing the fix is available. Can you please be more specific on the availability of the v10.1p build?

As for the timezone use case; the current expectation is that the scheduled (server-side) report always executes under the context of the server timezone, which is the current behaviour. The default behaviour cannot change here, however, we do have the desire to provide an enhancement in the future that would allow optionally overriding the timezone based on server-supplied user timezone information (we know who scheduled the report and we know the desired timezone of who scheduled the report), however, I believe this is already possible with your APIs today.

That being said, allowing for optionally including timezone information from the client with the relative date definitions, would seem like a useful extension.

Thanks

[Isomorphic]

It will be in tomorrow's build of 5.1p (aka SmartClient 10.1p)

[stonebranch2]

Hi Isomorphic,

Just a follow up; without any code changes, the behaviour is working as expected for my use case now. Thanks.

However, I assumed that for any call to AdvancedCriteria.convertRelativeDates(), there would be a new method that could be called to pass in the DataSource, specifically, AdvancedCriteria.convertRelativeDates(DataSource).

However, there appears to only be one method that takes the DataSource parameter, specifically, AdvancedCriteria.convertRelativeDates(Date, DataSource), which pairs with the other method AdvancedCriteria.convertRelativeDates(Date).

Regards

[stonebranch2]

Hi Isomorphic,
Any update on this one?
Thanks

[stonebranch2]

Hi Isomorphic,
We need to decide if we will incorporate the additional recommendation you made with respect to the API, however, without the API available, we are still awaiting your feedback. If you have a moment to update this thread, it would be much appreciated.
Thank you

[Isomorphic]

Sorry for the delay: a problem with our build server meant we didn't have new builds going up for a day or two, and we were waiting until that was resolved before posting. We have added a version of the API that just accepts a DataSource - AdvancedCriteria.convertRelativeDates(DataSource). Note that this is only for completeness / consistency - you would get exactly the same result by calling the (Date, DataSource) version with a null first parameter.

Regards,
Isomorphic Software Support

[stonebranch2]

Thank you.
We have changed our code to utilize the convenience method.
Regards