Backendless Version (3.x / 5.x, Online / Managed / Pro )
6.4.12
Client SDK (REST / Android / Objective-C / Swift / JS )
REST in normal cases.
Application ID
5FB0EA72-A363-4451-FFA5-A56F031D6600
Expected Behavior
Utc date integer, in seconds, micro or nano… to be compared correctly with the stored dates in db using regular comparison operators < > =
Actual Behavior
the db query retrieves dates that doesn’t match the where clause.
Reproducible Test Case
Date.now() is used below for the example, normally we pass a utc integer date using REST.
const d = Date.now();
console.log(d);
var whereClause = "'" + d + "' < leavingDate";
//var whereClause = " '01/10/2022 00:37:14' < leavingDate";
//var whereClause = "'2021-12-13T14:32:00.000Z' < leavingDate";
var queryBuilder = Backendless.DataQueryBuilder.create().setWhereClause(whereClause);
var ridesFound = await Ride.find(queryBuilder);
return ridesFound
1 Like
Could you “console.log” the final where clause and post it here?
console log of where clause:
‘1639323436887’ < leavingDate
the REST request where clause from the frontend:
leavingDate >= ‘2021-12-13T14:32:00.000Z’
both of them don’t work properly.
I’m using this tool to convert integer to date:
Make sure to test your where clause in rest console first (on the Data screen). The following where clause is incorrect:
‘1639323436887’ < leavingDate
the correct version would look like this:
leavingDate > 1639323436887
when using timestamps for dates in the database, the value must be numeric (not enclosed in single quotes). The documentation provides examples for that:
https://backendless.com/docs/js/data_search_with_dates.html
Mark
this was wrong but still it did not solve the problem.
where clause:
1639328153194 < leavingDate
response:
[]
where clause:
now() < leavingDate
response:
[{object1}, {object2}]
the second whereClause return the right data, but the first doesn’t.
the leavingDate column in our db(only first page):
Try swapping the number and the name of the column around, like this:
leavingDate > 1639328153194
the bug didn’t appear anymore, although we didn’t change anything on our code, we couldn’t identify the cause of the invalid results, but since the problem disappeared I’ll accept the answer as solution and will open new one if something similar happens again
thank you for your support Mark!
