[last_activity_at] references that any event for the project will update that value as well as provide a list of actions that would generate events.
So I go to this api endpoint and check that last activity on this project was at 2023-09-30T15:16:50.616Z (yup, definitely more than a week ago) which is 100% not a 12h ago.
Longer story: The “Updated” time is based on 3 different sources from our backend: “last_activity_at”, “last_repository_updated_at”, and “updated_at”. Whichever one of these is most recent will be displayed. The problem however is that the “updated_at” source is not something that should be used for this, as it also includes activities that don’t count as activity or updates, and is also related to our caching.
As mentioned above, we have an issue open for that and will hopefully get to it soon, but that team is currently working on other high priority initiatives, so if anyone wants to contribute to get this done faster, there is a lot of guidance already in the issue about how this could potentially be fixed and you could ping the engineers involved in the issue for advice or the MR review.
I hope this at least explains why this is happening, even if I can’t offer a direct solution. Thanks everyone for reporting this!
In case it matters for evaluating the priority of this, this is part of the reason why I still give people my GitHub profile link rather than the GitLab one when I want to show them my FOSS work, despite having migrated all my work on GitLab, because it makes it impossible to have a good read on the timeline, showing archives or old projects on top, in a seemingly random order. For a bit of irony : I recently applied to GitLab, and I used my GitHub link to show them my work to be sure they can properly read the timing of it.