Best practice for mapping ~5-month road closure with approximate end date?

In this part of the map, the westbound lanes of Randolph Road are closed for construction from Parklawn Drive to Nebel Street until 2022-02-07, according to a sign I saw there on 2021-08-20. However, the sign has been removed since then, and I wouldn't be surprised if the end date changes by as much as a few weeks based on unpredictable factors affecting the progress of the construction project.

I'd like to map this closure in some form to help routers. I understand that there are two general approaches:

1. Edit the ways (in this case, make them one-way eastbound rather than highway=construction) and edit them back once I confirm the lanes have reopened.
2. Use time-based restrictions: something like oneway:conditional=yes @ 2021 Sep 06-2022 Feb 07.

On this wiki page, one question, and another question, I see that there are trade-offs and some debate about how to weigh the competing considerations and consequently what the best practice should be. If I'm certain of the end date (as well as the desired state of the map after that date, which I am in this case), then #2 is almost certainly better. But here I'm not completely certain of the end date, and at approximately 5 months, the length of the closure falls near the threshold that several users have said should decide between #1 and #2. Not finding any obvious local precedent, I believe I'm probably allowed the discretion to map the closure either way, but I thought it would be a good opportunity to solicit some more opinions here first. (Let me know if I should take this discussion to another place.)

Re "The original mapper may move or change hobbies by the time construction completes. The road will permanently be marked closed until someone else happens to notice": I hope I've already built some credibility by promptly reopening one closure for which I used approach #1, though of course, the community has the right not to believe me. The other serious concern with #1 is the concern that clients that use old data could see the road as closed for much longer than it actually is.

But ISTM #2 has problems of its own if the closure continues past the end date I originally enter: clients will start trying to route over the closed road until I have time to re-survey it and update the end date on OSM. If a new end date is not announced, I'm left to guess. In the worst case, ISTM we could end up with the road oscillating between open and closed from OSM's point of view, as I make a series of artificial updates to the guessed end date on OSM to try to keep up.

So I'd like a better sense of what is the least evil here and, if I go with #2, whether there's anything I can do to help manage the potential problem. (Might it make sense to deliberately enter an end date in OSM that is several weeks after the announced date and then update OSM if the road reopens before then?) I get the sense that the community doesn't have great data on how many users are using what update cycle for OSM data and how badly they would be affected by their app showing them a false positive versus a false negative road closure. I'd guess that a false positive (a suboptimal route) is less annoying than a false negative (being routed on a closed road and having to find a detour on the spot, though in this case, signs are posted for an adequate detour, so the impact would effectively just be a suboptimal route by the time the user takes the signed detour). But this is just based on my own experience as a user of OsmAnd with weekly live updates; I can't speak for all OSM clients.

Update 2021-09-08: Another problem with #2 is that some (most?) popular routers don't support oneway:conditional. OsmAnd does; I tested OSRM and it doesn't; and I think Valhalla doesn't based on a look at the source code. I don't know how heavily this consideration should be weighed. For now, I've gone ahead and used #2 with the OSM end date set to the originally signed end date of 2022-02-07, since I can't think of any sense in which that could be argued to be worse than the status quo, even if it isn't an ideal solution.

Thanks for your attention!