A problem I found there is the report doesn’t handle PH-2 days Sa off
I added a corresponding sample to Key:opening_hours#Examples
For Mar 01-easter + 38 days, the report suggests a change to Mar 01-easter +38 days. This might not be worth the edit. Even the format Mar 01 - easter+38days would be easier to read.
That’s rather an issue with the parsing library:
“Tu-Sa 09:00-17:00; PH -2 days <— (There should be no reason to differ more than 1 days from a public holiday. If so tell us …)”
That is on me though, it should be excluding purely changing spaces where it has no change in meaning, so I’ll do something to exclude that
A few recent updates to the tool:
You can now edit a value in place on the website, without jumping to another editor
(this has been the case for the totally invalid elements for a while, but is now also enabled for those with a suggested fix, useful when the fix isn’t quite right)
Then, thanks to work on the parsing library (not by me), we can now put a warning for when the hours value includes specific date information which is in the past.
Hi,
Thanks for the update!
I am not sure that date in past should be marked as “invalid date”. It is just a date in the past, an obsolete part in the field. It may probably be possible to propose a fixed for them. Like parse ; and if it contains only dates in the past remove that block?
Thanks for the update. Finally the updates to the general library went live!
Old dates are generally an indicator that a check of the actual hours is needed rather than a formal fix of the string. I noticed that some commercial mappers from France use fixed dates to add movable holidays.
Personally, I’d ignore dates that are in the current year.
If so, every node with check_date or check_date:opening_hours too old should be marked as “invalid” 
.
Yes, there is a lot of fixed dates imported in France for post offices (as far as I looked, it was that). But usually, the standard opening hours have not changed.
“Opening hours validation” is different to “opening hours reminder to update/check” IMHO. At least, the website should have a new category “deprecated/obsolete opening hours” to class them.
I guess I didn’t know what issues it would find before I added the check. I certainly hadn’t realised there were so many past dates in France.
I don’t think that just removing the old date section of the string is a good general solution though, perhaps the dates need to be updated to the current year instead.
I agree that it is a different sort of error to the ones that can’t be parsed and so perhaps it could go into a separate section.
A bot was running until 2024, any exceptional closure was automatically added to the opening hours (opening hours are in open data and well maintained). Therefore the exceptions in the past.
I didn’t ask David why his bot was not running anymore.
