All date time comparisons get broken in db queries using js Servercode, while we didn't change anything from our side

Backendless Version (3.x / 5.x, Online / Managed / Pro )


Client SDK (REST / Android / Objective-C / Swift / JS )

REST in normal cases.

Application ID


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 is used below for the example, normally we pass a utc integer date using REST.

const 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:


this was wrong but still it did not solve the problem.

where clause:

1639328153194 < leavingDate



where clause:

now() < leavingDate


[{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!