[Places] question about the sources.update_time in the 2025-02-19 release

[Guilherme de Oliveira (g-deoliveira)]

Category Feedback

Add details

• Expected behaviour you didn't see
• Unexpected behaviour
• suggested functionality
• Steps to reproduce the problem

Dependency with other categories, if any.

No response

[Guilherme de Oliveira (g-deoliveira)]

👋 Hi!
When you compare the places data across the pre-Feb 2025 release with the Feb 2025 release, you'll notice that the sources.update_time field was updated in some cases with a retroactive date. For instance for overture_places_id = 08f1f24a5d090c4c03264a91a6044233, the sources.update_time was set to 2024-09-10T00:00:00.000 prior to the Feb release and in the 2025-02-19 release, it was set to 2019-11-15T21:21:54.793. I poked around and found that the update_time is defined as { "$ref": "#/$defs/propertyDefinitions/featureUpdateTime" } in the schema/defs.yml. Could you verify that this change in date is correct and help me understand how to interpret it?
I appreciate your help!
Guilherme

[Stephen Epps (stepps00)]

Hi Guilherme de Oliveira (@g-deoliveira) I'm unable to confirm this change in date for id 08f1f24a5d090c4c03264a91a6044233. I see the following in February:

{'property': , 'dataset': Microsoft, 'record_id': 1688849866197546, 'update_time': 2024-11-19T11:13:52.050Z, 'confidence': 0.77}

and the following in January and September:

{'property': , 'dataset': msft, 'record_id': 1688849866197546, 'update_time': 2024-09-10T00:00:00.000Z, 'confidence': NULL}

Though I don't doubt that there are incorrectly set dates in a handful of cases. Would you be able to provide a few more examples? In general, these timestamps should not reverse in time; they represent the time when the feature was last updated. If you forward other examples, we can investigate and push an updated timestamp in the next release(s). Thank you!