Google People API - ordering by the update time not working as expected

I've been successfully using Google People API for retrieving my Google contacts, but I've discovered that API does not sort correctly by the last update time (eg. using setSortOrder("LAST_MODIFIED_DESCENDING")). What's more, it turns out that there is an interesting pattern when looking at the output of this code:

  private static void getLastModified() throws GeneralSecurityException, IOException {
    PeopleService service = getService();
    ListConnectionsResponse response =
        service.people().connections().list("people/me")
        .setPageSize(30)
        .setPersonFields("names,metadata")
        .setSortOrder("LAST_MODIFIED_DESCENDING")
        .execute();
    for (Person person : response.getConnections()) {
      //System.out.println(person.getNames());
      for (Source s : person.getMetadata().getSources()) {
        if (s.getType().equals("CONTACT")) {
          System.out.println(s.getUpdateTime());
        }
      }
    }
  }

Results with LAST_MODIFIED_DESCENDING sorting order:

2020-05-07T19:27:27.469Z    <-- ok (which means this contact is for sure modified by me on the given day)
2020-05-07T19:27:03.418Z    <-- ok
2020-05-07T19:26:20.219Z    <-- ok
2020-05-07T19:25:39.684Z    <-- ok
2020-05-07T19:25:13.823Z    <-- ok
2020-05-07T19:24:13.732Z    <-- ok
2020-05-07T13:04:47.637Z    <-- ok
2020-04-12T17:18:31.714156Z <-- NOT ok (contact is probably modified by me on that day, but why is it positioned incorrectly?)
2020-04-15T20:49:28.733412Z <-- NOT ok
2020-05-06T17:20:19.840Z    <-- ok
2020-05-06T17:18:22.134Z    <-- ok
2020-05-06T17:17:33.185Z    <-- ok
2020-05-06T16:41:00.368Z    <-- ok
2020-05-06T16:40:50.119Z    <-- ok
2020-05-06T15:02:49.218Z    <-- ok
2020-05-06T14:29:27.963Z    <-- ok
2020-05-06T14:28:40.890Z    <-- ok
2020-05-06T14:26:56.322Z    <-- ok
2020-05-06T14:26:04.658Z    <-- ok
2020-05-06T14:25:17.177Z    <-- ok
2020-05-06T14:24:12.801Z    <-- ok
2020-05-06T14:23:13.461Z    <-- ok
2020-05-06T14:22:04.888Z    <-- ok
2020-04-12T19:26:25.392253Z <-- NOT ok
2020-05-06T12:05:32.209Z    <-- ok
2020-05-06T11:57:11.286Z    <-- ok
2018-08-15T13:49:04.254001Z <-- NOT ok
2020-04-12T15:10:27.421184Z <-- NOT ok
2020-05-05T17:51:52.572Z    <-- ok
2020-05-05T17:50:43.904Z    <-- ok

After analysing this further, it looks like all misplaced contacts have two types of source object in their metadata structure (CONTACT and PROFILE) of which only CONTACT contains the updateTime timestamp but API obviously takes into the account the other one - the PROFILE timestamp that is NOT visible via API. In other words, misplaced contacts from my list are probably not misplaced, they are rather changed from their original owner, but the API doesn't reveal this second timestamp.

Can someone shed some more light on this and suggest how to force API to ignore the PROFILE metadata source and sort only according to my modification timestamps?

Solution

Thanks to the @Raserhin for the suggestion to post the issue to Google Issue Tracker - I did that, got an answer and I am able to answer my own question.

As for the first part of the question:

Can someone shed some more light on this ...?

At https://issuetracker.google.com/issues/156048409 I got a detailed explanation which proved my speculations:

Our backend service does the sorting based on the last modified timestamp from both contacts and profiles contained in a given merged person. However when our People service passes through the data, it only exposes the timestamp from contacts, not from profiles. Yes, it is not an informative API design, when the sorting key fields are not fully returned. But I need to run the idea within the team and privacy review, if we want to expose the profile change timestamp.

Second part of the question:

how to force API to ignore the PROFILE metadata source and sort only according to my modification timestamps?

API obviously can't do that at the moment so each developer who needs to use this type of sorting will have to take described behaviour into account and choose either to accept it or create a workaround (eg. retrieve all the contacts and sort them in place if it's not too expensive).